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(at)2ndquadrant(dot)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,
--
Casey