On 2017-03-07 21:48:23 -0500, Robert Haas wrote:
> On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson <andreas@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'tbe 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