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

From Gregory Stark
Subject Re: Tricky bugs in concurrent index build
Date
Msg-id 87zmdvxvq0.fsf@enterprisedb.com
Whole thread Raw
In response to Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Tricky bugs in concurrent index build
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> I think that's OK, but the whole idea of using an MVCC snap in phase 2
> doesn't work on closer inspection.  The problem is still the same one
> that you need to take (at least) share lock on each tuple you insert
> into the index.  Telling aminsert to check uniqueness implicitly assumes
> the new tuple is live, and without any lock on the tuple you can't
> promise that.  

No wait. It's still "live" according to my snapshot. How could it be possible
for a single snapshot to see two different versions of the same tuple as live?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: Replication
Next
From: Jeff Davis
Date:
Subject: Re: Replication