Re: Support for REINDEX CONCURRENTLY
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-12-08T12:24:47Z
Lists: pgsql-hackers
On Sat, Dec 8, 2012 at 2:19 AM, Andres Freund <andres@2ndquadrant.com>wrote: > On 2012-12-07 12:01:52 -0500, Tom Lane wrote: > > Simon Riggs <simon@2ndQuadrant.com> writes: > > > On 7 December 2012 12:37, Michael Paquier <michael.paquier@gmail.com> > wrote: > > >> - There is still a problem with toast indexes. If the concurrent > reindex of > > >> a toast index fails for a reason or another, pg_relation will finish > with > > >> invalid toast index entries. I am still wondering about how to clean > up > > >> that. Any ideas? > > > > > Build another toast index, rather than reindexing the existing one, > > > then just use the new oid. > > Thats easier said than done in the first place. toast_save_datum() > explicitly opens/modifies the one index it needs and updates it. > > > Um, I don't think you can swap in a new toast index OID without taking > > exclusive lock on the parent table at some point. > > The whole swapping issue isn't solved satisfyingly as whole yet :(. > > If we just swap the index relfilenodes in the pg_index entries itself, > we wouldn't need to modify the main table's pg_class at all. > I think you are mistaking here, relfilenode is a column of pg_class and not pg_index. So whatever the method used for swapping: relfilenode switch or relname switch, you need to modify the pg_class entry of the old and new indexes. -- 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