Greg Stark <gsst...@mit.edu> writes:
> On Wed, Apr 20, 2011 at 3:35 PM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
