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: Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-12-08T12:31:13Z
Lists: pgsql-hackers
On Sat, Dec 8, 2012 at 2:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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.) > Yes. reltoastidxid refers to the index of the toast table so it is necessary to take a lock on the parent relation in this case. I haven't thought of that. I also do not really know how far this is used by the toast process, but just by thinking safety taking a lock on the parent relation would be better. For a normal index, locking the parent table is not necessary as we do not need to modify anything in the parent relation entry in pg_class. -- 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