Re: Support for REINDEX CONCURRENTLY

On 2013-01-27 07:54:43 +0900, Michael Paquier wrote:

I think you're misunderstanding how this part works a bit. We don't
acquire locks on the table itself, but we get a list of all transactions
we would conflict with if we were to acquire a lock of a certain
strength on the table (GetLockConflicts(locktag, mode)). We then wait
for each transaction in the resulting list via the VirtualXact mechanism
(VirtualXactLock(*lockholder)).
It doesn't matter all that waiting happens in the same transaction the
initial index build is done in as long as we keep the session locks
preventing other schema modifications. Nobody can go back and see an
older index list after we've done the above wait once.

So the following should be perfectly fine:

StartTransactionCommand();
BuildListOfIndexes();
foreach(index in indexes)
    DefineNewIndex(index);
CommitTransactionCommand();

StartTransactionCommand();
foreach(table in tables)
    GetLockConflicts()
foreach(conflict in conflicts)
    VirtualXactLocks()
CommitTransactionCommand();

foreach(index in indexes)
    StartTransactionCommand();
    InitialIndexBuild(index)
    CommitTransactionCommand();

> It looks that this feature has still too many disadvantages compared to the

> advantages it could bring in the current infrastructure (SnapshotNow
> problems, what to do with invalid toast indexes, etc.), so I would tend to
> agree with Tom and postpone this feature once infrastructure is more
> mature, one of the main things being the non-MVCC'ed catalogs.

I think while catalog mvcc snapshots would make this easier, most
problems, basically all but the switching of relations, are pretty much
independent from that fact. All the waiting etc, will still be there.

I can see an argument for pushing it to the next CF because its not
really there yet...