On 2017-03-07 21:48:23 -0500, Robert Haas wrote: > On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson <andr...@proxel.se> wrote: > > And I would argue that his feature is useful for quite many, based on my > > experience running a semi-large database. Index bloat happens and without > > REINDEX CONCURRENTLY it can be really annoying to solve, especially for > > primary keys. Certainly more people have problems with index bloat than the > > number of people who store index oids in their database. > > Yeah, but that's not the only wart, I think.
I don't really see any other warts that don't correspond to CREATE/DROP INDEX CONCURRENTLY. > For example, I believe (haven't looked at this patch series in a > while) that the patch takes a lock and later escalates the lock level. It shouldn't* - that was required precisely because we had to switch the relfilenodes when the oid stayed the same. Otherwise in-progress index lookups could end up using the wrong relfilenodes and/or switch in the middle of a lookup. * excepting the exclusive lock DROP INDEX CONCURRENTLY style dropping uses after marking the index as dead - but that shouldn't be much of a concern? > Also, if by any chance you think (or use any software that thinks) > that OIDs for system objects are a stable identifier, this will be the > first case where that ceases to be true. Can you come up with an halfway realistic scenario why an index oid, not a table, constraint, sequence oid, would be relied upon? > If the system is shut down or crashes or the session is killed, you'll > be left with stray objects with names that you've never typed into the > system. Given how relatively few complaints we have about CIC's possibility of ending up with invalid indexes - not that there are none - and it's widespread usage, I'm not too concerned about this. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
