Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

On Sat, Oct 6, 2012 at 12:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 1. These operations think they can use ordinary heap_update operations
> to change pg_index entries when they don't have exclusive lock on the
> parent table.

I wonder if we need a manual that lists exhaustively what operations
can be taken with locks on various objects. Relying on understanding
every other possible operation in the system and knowing which
operations might or might not happen is clearly getting us into
trouble.

This would be a lot less worrying if we had a regression test suite
that could reliably test race conditions like this.

> The lack of ex-lock means that another backend could be
> currently loading up its list of index OIDs for the table --- and since
> it scans pg_index with SnapshotNow to do that, the heap_update could
> result in the other backend failing to see this index *at all*. That's
> okay if it causes the other backend to not use the index for scanning...
> but not okay if it causes the other backend to fail to make index
> entries it is supposed to make.

I marked this email to read later but now I'm reading it and I realize
I'm not sure I can really help. Using a nontransactional update to
flag indisready makes sense to me since the whole point of the wait is
that we've waited long enough that anyone should see this record. I
guess that's what I had in mind was happening when I wrote the update.
But I'm not sure what other requirements nontransactional updates have
to work properly.

--
greg