Re: SSI bug? - Mailing list pgsql-hackers

From yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Subject Re: SSI bug?
Date
Msg-id 20110212070822.46BE319D15D@mail.netbsd.org
Whole thread Raw
In response to Re: SSI bug?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI bug?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
hi,

> YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
>  
>> it seems that PredicateLockTupleRowVersionLink sometimes create
>> a loop of targets (it founds an existing 'newtarget' whose
>> nextVersionOfRow chain points to the 'oldtarget') and it later
>> causes CheckTargetForConflictsIn loop forever.
>  
> Is this a hypothetical risk based on looking at the code, or have
> you seen this actually happen?  Either way, could you provide more
> details?  (A reproducible test case would be ideal.)

i have seen this actually happen.  i've confirmed the creation of the loop
with the attached patch.  it's easily reproducable with my application.
i can provide the full source code of my application if you want.
(but it isn't easy to run unless you are familiar with the recent
version of NetBSD)
i haven't found a smaller reproducible test case yet.

YAMAMOTO Takashi

>  
> This being the newest part of the code, I'll grant that it is the
> most likely to have an unidentified bug; but given that the pointers
> are from one predicate lock target structure identified by a tuple
> ID to one identified by the tuple ID of the next version of the row,
> it isn't obvious to me how a cycle could develop.
>  
> -Kevin

pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: pl/python custom exceptions for SPI
Next
From: Ralf Wildenhues
Date:
Subject: Re: [Mingw-users] mingw64