From: | yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi) |
---|---|
To: | Kevin(dot)Grittner(at)wicourts(dot)gov |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI bug? |
Date: | 2011-02-12 07:08:21 |
Message-ID: | 20110212070822.46BE319D15D@mail.netbsd.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
hi,
> YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)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
Attachment | Content-Type | Size |
---|---|---|
a.diff | text/plain | 945 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2011-02-12 07:53:14 | Re: arrays as pl/perl input arguments [PATCH] |
Previous Message | Greg Smith | 2011-02-12 04:57:02 | Re: Debian readline/libedit breakage |