[elephant-devel] Re: Postmodern regression

[Leslie P. Polzer]

> also, it's not clear what happens if transaction is rolled back -- is
> prepared statement rolled back too, or it is memorized?
> it seems this way our idea of memorized statements and db session can be
> desynchronized, but actually in _oposite direction_: our code will think
> that it's there, but it is not.

Yeah, and I think I finally found the cause of this problem, and
also why it only occurred sometimes.

Observe this trace:

...
    1: (DB-POSTMODERN::ENSURE-PREPARED-ON-CONNECTION
        COMMON-LISP-USER::TREE10SELECT "TREE10SELECT"
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "select bob from tree10,blob where qi=$1 and bid = value")
      2: (CL-POSTGRES:CONNECTION-META
          #<CL-POSTGRES:DATABASE-CONNECTION {C883481}>)
      2: CL-POSTGRES:CONNECTION-META returned
           #<HASH-TABLE :TEST EQL :COUNT 20 {D2C1C91}>

Keep in mind that TREE10SELECT is interned in CL-USER here (for whatever
reason).

This is the CL-POSTGRES meta information (an EQL hash table)
associated with this session:

SLOTSSELECT->T
SP-META-SELECT->T
TREE11SET->T
TREE10SELECT->T
^^^^^^^^^^^^^^^
TREE11SELECT->T
SP-ENSURE-BID->T
SLOTSINSERT->T
CLASSROOTSELECT->T
SP-METATREE-INSERT->T
TREE51INSERT->T
TREE53INSERT->T
TREE31INSERT->T
TREE121656INSERT->T
TREE121656FIRST->T
TREE121656NEXT->T
TREE121656SELECT->T
TREE121656DELETE->T
TREE121656NOTIFY-UPDATE->T
COMMON-LISP-USER::TREE10FIRST->T
COMMON-LISP-USER::TREE10NEXT->T

As you can see, the symbol recorded in the hash table is interned in
the current package (not CL-USER in this case!).

Thus our lookup reports that the query is not prepared:

gethash: NIL

Leading to an erroneous preparation of it:

      2: (CL-POSTGRES:PREPARE-QUERY
          #<CL-POSTGRES:DATABASE-CONNECTION {C883481}> "TREE10SELECT"
          "select bob from tree10,blob where qi=$1 and bid = value")


> i think that instead of blindly retrying txn we should find cause of this
> problem

Yes -- I was finally determined to solve this once and for all
because retrying obviously did not help.


>  LPP> I have also tried deallocating the statement in question
>
> why do you want to deallocate it -- you think old one is bad? :)

You made me laugh here :) Guess it seemed like an easy way out,
plus Henrik's original code also used this strategy.


> if it's there but we don't know about it, we can just mark statement as
> prepared so further call won't try to prepare it.

Would probably help. I won't count on it with all the package name
confusion...

I have solved this right now by using keywords. Patch attached,
runs green for me.


>  LPP> before invoking the restart but it seems that any execution of
>  LPP> SQL at this time will hang indefinitely.
>  LPP> Do you have any idea why this would happen?
>
> never seen postgres hanging. if txn is aborted, it just ignores all
> sebsequent statements. but is should not hang..

Could you do me a favor? Try running the Elephant backend test suite
(preferably with PM backend), say, 15 times in a row in 1.0.1x SBCL
and tell me whether it hangs for you at some point, too.

  Leslie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbpm-prepared-fix.patch
Type: text/x-patch
Size: 21970 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20080430/8491f88f/attachment.bin>