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=
