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: 2013-02-13T06:55:23Z
Lists: pgsql-hackers
Attachments
- 20130213_reindex_concurrently_v10.patch (application/octet-stream) patch v10
Hi, Please find attached a new version of the patch incorporating the 2 fixes requested: - Fix for to insert new data to multiple toast indexes in toast_save_datum if necessary - Fix the lock wait phase with new function WaitForMultipleVirtualLocks allowing to perform a wait on multiple locktags at the same time. WaitForVirtualLocks uses also WaitForMultipleVirtualLocks but on a single locktag. I am still looking at the approach removing reltoastidxid, approach more complicated but cleaner than what is currently done in the patch. Regards, On Tue, Feb 12, 2013 at 10:04 PM, Andres Freund <andres@2ndquadrant.com>wrote: > On 2013-02-12 21:54:52 +0900, Michael Paquier wrote: > > > Changing only toast_save_datum: > > > > > > [... code ...] > > > > > Yes, I have spent a little bit of time looking at the code related to > > retoastindxid and thought about this possibility. It would make the > changes > > far easier with the existing patch, it will also be necessary to update > the > > catalog pg_statio_all_tables to make the case where OID is InvalidOid > > correct with this catalog. > > What I proposed above wouldn't need the case where toastrelidx = > InvalidOid, so no need to worry about that. > > > However, I do not think it is as clean as simply > > removing retoastindxid and have all the toast APIs running consistent > > operations, aka using only RelationGetIndexList. > > Sure. This just seems easier as it really only requires changes inside > toast_save_datum() and which mostly avoids any overhead (not even > additional palloc()s) if there is only one index. > That would lower the burden of proof that no performance regressions > exist (which I guess would be during querying) and the amount of > possibly external breakage due to removing the field... > > Not sure whats the best way to do this when committing. But I think you > could incorporate something like the proposed to continue working on the > patch. It really should only take some minutes to incorporate it. > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > -- Michael
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