Re: Support for REINDEX CONCURRENTLY
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael.paquier@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-12-07T18:17:48Z
Lists: pgsql-hackers
On 7 December 2012 17:19, 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. Well, yeh, I know what I'm saying: it would need to maintain 2 indexes for a while. The point is to use the same trick we do manually now, which works fine for normal indexes and can be made to work for toast indexes also. >> 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. yes -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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