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

On Oct 22, 2014, at 9:21 AM, Andres Freund <andres@2ndquadrant.com> =
wrote:
> Even if it doesn't arrise to the level of data corruption, I suspect =
in
> many cases updating the stats nontransactionally in an later aborted
> transaction will surprise some users. The normal reason for doing a
> ANALYZE in a transaction is that you changed the data dramatically.

I agree.  If stats were updated after a transaction were rolled back, =
this would be bad.  If the purpose of the ANALYZE is that otherwise =
queries are slow after a reload, and the transaction fails and we go =
back to old data, the expectation should be that old performance and =
output resumes, not bad performance with old output due to corrupted =
stats.

> It probably should at least LOG/WARN, to make it clear that things =
were
> in a bad shape. It might be helpful to allow VACUUM/ANALYZE to fix
> existing corrupted relhas* flags. Although there could already be
> existing corruption, in which case users might want to get alerted of
> that more aggressively.

As a user, I would prefer to see an error - assuming there were a way to =
deal with it manually in separate steps somehow - if there were =
pre-existing corruption that needed to be dealt with.  A warning could =
be sufficient, but I would definitely not want it to be silent, because =
I think that would potentially hide corruption issues...a problem could =
exist undetected for longer with something else silently cleaning up =
after it.

Best wishes,
--=20
Casey=