Re: WIP: Detecting SSI conflicts before reporting constraint violations

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: WIP: Detecting SSI conflicts before reporting constraint violations
Дата
Msg-id CAEepm=0p3bjyuUCxkMcGcdkDg65GGXSVwQKrq=MvGGjJSZtMOQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: Detecting SSI conflicts before reporting constraint violations  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Refectoring of receivelog.c
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Logical decoding slots can go backwards when used from SQL, docs are wrong