Re: Support for REINDEX CONCURRENTLY

Michael Paquier <michael.paquier@gmail.com>

From: Michael Paquier <michael.paquier@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <stark@mit.edu>, Andres Freund <andres@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-10-04T05:03:24Z
Lists: pgsql-hackers
On Thu, Oct 4, 2012 at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Greg Stark <stark@mit.edu> writes:
> > I'm a bit puzzled why we're so afraid of swapping the relfilenodes
> > when that's what the current REINDEX does.
>
> Swapping the relfilenodes is fine *as long as you have exclusive lock*.
> The trick is to make it safe without that.  It will definitely not work
> to do that without exclusive lock, because at the instant you would try
> it, people will be accessing the new index (by OID).
>
OK, so index swapping could be done by:
1) Index name switch. This is not thought as safe as the system does not
pay attention on index names at all.

2) relfilenode switch. An ExclusiveLock is necessary.The lock that would be
taken is not compatible with a concurrent operation, except if we consider
that the lock will not be taken for a long time, only during the swap
moment. Reindex uses this mechanism, so it would be good for consistency.

3) Switch the OIDs of indexes. Looks safe from the system prospective and
it will be necessary to invalidate the cache entries for both relations
after swap. Any opinions on this one?
-- 
Michael Paquier
http://michael.otacoo.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.