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