Re: Tricky bugs in concurrent index build - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: Tricky bugs in concurrent index build
Date
Msg-id E1539E0ED7043848906A8FF995BDA57901410127@m0143.s-mxs.net
Whole thread Raw
In response to Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > Is it not possible to brute force this adding an AM method to insert

> > without the uniqueness check?
>
> Hm.  Actually there already is a feature of aminsert to allow
> suppressing the unique check, but I'm not sure whether using
> it for RECENTLY_DEAD tuples helps.  Seems like we have to
> wait to see whether DELETE_IN_PROGRESS deleters commit in any case.

Um, but if we wait for the DELETE_IN_PROGRESS tuple, after the wait we
can
add it eighter with or without the unique check (depending on
commit/abort).

Then at least we don't need to wait in a 3rd pass for readers ?

Andreas


pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: [PATCHES] COPY view
Next
From: Martijn van Oosterhout
Date:
Subject: Re: pg_upgrade: What is changed?