Re: WIP: Detecting SSI conflicts before reporting constraint violations - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WIP: Detecting SSI conflicts before reporting constraint violations
Date
Msg-id CAEepm=0p3bjyuUCxkMcGcdkDg65GGXSVwQKrq=MvGGjJSZtMOQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Detecting SSI conflicts before reporting constraint violations  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Fri, Mar 11, 2016 at 6:31 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> This patch introduces a drop-in replacement
> check_unique_tuple_still_live to call instead of heap_hot_search.  The
> replacement function also calls heap_hot_search_buffer, but while it
> has the buffer it takes the opportunity to do an SSI conflict-in
> check.  At that point we know that the transaction is already doomed
> to ereport, it's just a question of figuring out whether it should
> ereport 40001 first.

Upon reflection, I want to forget about all that for now and propose
just a one line addition to _bt_check_unique that can handle the
explicit read-then-write cases reported.  See attached.

(There may be a separate follow-up patch that refactors to examine
heap tuples like in the previous version, if that turns out to be
necessary to detect more complicated cases like "r2 w1 w2 c1 c2" (as I
suspect), but I'm not sure about that or if I'll be able to do that
for this CF and until then there's no point in arranging the code that
way.)

--
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Refectoring of receivelog.c
Next
From: Craig Ringer
Date:
Subject: Re: Logical decoding slots can go backwards when used from SQL, docs are wrong