On Thu, Mar 2, 2017 at 11:48 AM, Andres Freund <and...@anarazel.de> wrote: > On 2017-03-01 19:25:23 -0600, Jim Nasby wrote: >> On 2/28/17 11:21 AM, Andreas Karlsson wrote: >> > The only downside I can see to this approach is that we no logner will >> > able to reindex catalog tables concurrently, but in return it should be >> > easier to confirm that this approach can be made work. >> >> Another downside is any stored regclass fields will become invalid. >> Admittedly that's a pretty unusual use case, but it'd be nice if there was >> at least a way to let users fix things during the rename phase (perhaps via >> an event trigger). > > I'm fairly confident that we don't want to invoke event triggers inside > the CIC code... I'm also fairly confident that between index oids > stored somewhere being invalidated - what'd be a realistic use case of > that - and not having reindex concurrently, just about everyone will > choose the former.
Maybe. But it looks to me like this patch is going to have considerably more than its share of user-visible warts, and I'm not very excited about that. I feel like what we ought to be doing is keeping the index OID the same and changing the relfilenode to point to a newly-created one, and I attribute our failure to make that design work thus far to insufficiently aggressive hacking. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
