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