Re: REINDEX vs broken HOT chains, redux

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Wed, Apr 20, 2011 at 3:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> System indexes really
>> shouldn't be that much different from ordinary indexes. The property
>> we actually are relying on is that there can't be any HOT chains that
>> break the index, because it existed before any updates could have
>> happened. I think the new approach is a more direct implementation of
>> that concept than the original.

> The problem was caused by a recursive update to pg_index. We need to
> somehow ensure that update doesn't happen. We can either rely on this
> subtle property we've established is true today but depends on lots of
> fiddly bits of behaviour throughout the system or we can insert a line
> saying "just don't do that".

The problem with just adding a line saying "don't do that" is that it'll
fail (in a different way from the current problem) if there's ever a
situation where you *do* need it to do that. So I don't find that way
to be any more future-proof. In particular, the previous fix
essentially broke any attempt to add an index to a system catalog after
initdb, since it was highly likely to result in falsely labeling the new
index as not-indcheckxmin. We know that people do try to add new
indexes to catalogs, so I wasn't pleased at all with that behavior of
the previous patch --- but I didn't see another solution at the time.

With the new patch you can still get screwed if you add an index to
pg_index (and it's indcheckxmin and then you REINDEX it) --- but that's
a much smaller bug surface, and it doesn't intersect any use cases I've
heard of.

regards, tom lane