On Thu, May 16, 2019 at 2:03 PM Andres Freund <and...@anarazel.de> wrote:
> Hi, > > On 2019-05-16 13:59:47 -0700, Melanie Plageman wrote: > > On Wed, May 15, 2019 at 10:32 PM Ashwin Agrawal <aagra...@pivotal.io> > wrote: > > > > > > > > The second index would help to hold the session after inserting the > tuple > > > in unique index but before completing the speculative insert. Hence, > helps > > > to create the condition easily. I believe order of index insertion is > > > helping here that unique index is inserted and then non-unique index is > > > inserted too. > > > > > > > > Oh, cool. I didn't know that execution order would be guaranteed for > which > > index > > to insert into first. > > It's not *strictly* speaking *always* well defined. The list of indexes > is sorted by the oid of the index - so once created, it's > consistent. But when the oid assignment wraps around, it'd be the other > way around. But I think it's ok to disregard that - it'll never happen > in regression tests run against a new cluster, and you'd have to run > tests against an installed cluster for a *LONG* time for a *tiny* window > where the wraparound would happen precisely between the creation of the > two indexes. > > Makes sense? > Yep, thanks. > I guess we could make that case a tiny bit easier to diagnose in the > extremely unlikely case it happens by having a step that outputs > SELECT 'index_a'::regclass::int8 < 'index_b'::regclass::int8; > > Good idea. I squashed the changes I suggested in previous emails, Ashwin's patch, my suggested updates to that patch, and the index order check all into one updated patch attached. -- Melanie Plageman
0003-Add-test-to-validate-speculative-wait-is-performed.patch
Description: Binary data
