|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Subject:||Re: REINDEX CONCURRENTLY 2.0|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2017-03-07 21:48:23 -0500, Robert Haas wrote:
> On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson <andreas(at)proxel(dot)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
> 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
> 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
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.
|Next Message||David Steele||2017-03-08 03:23:14||Re: Protect syscache from bloating with negative cache entries|
|Previous Message||Andres Freund||2017-03-08 03:03:40||Re: Skip all-visible pages during second HeapScan of CIC|