Re: Support for REINDEX CONCURRENTLY
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-12-07T17:01:52Z
Lists: pgsql-hackers
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. 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. One sticking point is the need to update pg_class.reltoastidxid. I wonder how badly we need that field though --- could we get rid of it and treat toast-table indexes just the same as normal ones? (Whatever code is looking at the field could perhaps instead rely on RelationGetIndexList.) regards, tom lane
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