Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done

On 2014-10-28 19:28:05 -0400, Tom Lane wrote:
> I wrote:
> > I think that a better answer is to continue to do this update
> > nontransactionally, but to not let the code clear relhasindex etc
> > if we're inside a transaction block. It is certainly safe to put
> > off clearing those flags if we're not sure that we're seeing a
> > committed state of the table's schema.
>
> Attached is a proposed patch to do it that way. I borrowed Michael's
> test case.

I still think it'd be better to use a transactional update. But I also
*do* agree that this is the safer way forward for now. So +1 from me.

> + * In addition to fundamentally nontransactional statistics such as
> + * relpages and relallvisible, we try to maintain certain lazily-updated
> + * DDL flags such as relhasindex, by clearing them if no longer correct.
> + * It's safe to do this in VACUUM, which can't run in parallel with
> + * CREATE INDEX/RULE/TRIGGER and can't be part of a transaction block.

> + * However, it's *not* safe to do it in an ANALYZE that's within a
> + * transaction block, because the current transaction might've dropped
> + * the last index; we'd think relhasindex should be cleared, but if the
> + * transaction later rolls back this would be wrong. So we refrain from
> + * updating the DDL flags if we're inside a transaction block. This is
> + * OK since postponing the flag maintenance is always allowable.
> + *

Absolutely minor nitpick: It nearly sounds like this is only a concern
for relhasindex - but it's just as much a problem for other relhas*
stuff. Not sure if it's worth complicating the text for that. Maybe a
'e.g.'.

Greetings,

Andres Freund