Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

On 2012-10-05 19:56:40 -0400, Tom Lane 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. 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 think this could possibly be fixed by using nontransactional
> update-in-place when we're trying to change indisvalid and/or
> indisready, but I've not really thought through the details.

I couldn't really think of any realistic method to fix this other than
update in place. I thought about it for a while and I think it should
work, but I have to say it makes me slightly uneasy.

If we could could ensure both land on the same page it would be possible
to fix in a nicer way, but thats not really possible. Especially not in
any way thats backpatchable.

Unless somebody has a better idea I am going to write a patch for that.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services