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 →
-
Background worker processes
- da07a1e85651 9.3.0 cited
-
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
- 3c84046490be 9.3.0 cited
-
Work around unportable behavior of malloc(0) and realloc(NULL, 0).
- 09ac603c36d1 9.3.0 cited
-
Properly set relpersistence for fake relcache entries.
- beb850e1d873 9.3.0 cited