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: Andres Freund <andres@2ndQuadrant.com>, Michael Paquier <michael.paquier@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2012-12-09T17:29:05Z
Lists: pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes: > On 8 December 2012 15:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Or we could wait for MVCC catalog access ... > If there was a published design for that, it would help believe in it more. > Do you think one exists? Well, there have been discussion threads about it in the past. I don't recall whether any insoluble issues were raised. I think the concerns were mostly about performance, if we start taking many more snapshots than we have in the past. The basic idea isn't hard: anytime a catalog scan is requested with SnapshotNow, replace that with a freshly taken MVCC snapshot. I think we'd agreed that this could safely be optimized to "only take a new snapshot if any new heavyweight lock has been acquired since the last one". But that'll still be a lot of snapshots, and we know the snapshot-getting code is a bottleneck already. I think the discussions mostly veered off at this point into how to make snapshots cheaper. 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