On Mon, 2009-10-19 at 12:07 -0400, Tom Lane wrote:
> Brad Nicholson <bnichols@ca.afilias.info> writes:
> > If you issue an immediate shutdown to the database, autovacumm will not
> > process tables that should be vacuumed until manually re-analyzed.
>
> AFAICS this is an unsurprising consequence of flushing stats on a crash.
> If you don't like it, avoid immediate shutdowns --- they are not
> especially good practice in any case.
>
> > 3: What is the best work around for this? When our HA solution triggers
> > a DB shutdown, we want it to be immediate.
>
> That seems like a fundamentally stupid idea, unless you are unconcerned
> with the time and cost of getting the DB running again, which seemingly
> you are.
>
I disagree that this is fundamentally stupid. We are talking about a
situation where the server is about to die, HA solution kicks in and
moves it to standby.
If we wait for a clean shutdown instead, and the server dies before it
completes (which is entirely possible), Postgres crashes and the exact
same behaviour will happen. It also means that if any server crashes
(HA aside, shutdown method aside), the database will come up, but
functionality may be impacted until manual intervention.
At the very least. shouldn't autoanalyze not correct the lack of
statistics? To me, this looks like the database will not come up
cleanly after crashing.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.