On Mon, 2009-10-19 at 11:16 -0600, Scott Marlowe wrote:
> On Mon, Oct 19, 2009 at 11:06 AM, Brad Nicholson
> <bnichols@ca.afilias.info> wrote:
> > On Mon, 2009-10-19 at 10:53 -0600, Scott Marlowe wrote:
> >> On Mon, Oct 19, 2009 at 10:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> > Brad Nicholson <bnichols@ca.afilias.info> writes:
> >> >> On Mon, 2009-10-19 at 12:07 -0400, Tom Lane wrote:
> >> >>> 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.
> >> >
> >> > Moving it to standby immediately is a good idea, but it does not follow
> >> > that you need to hit the DB over the head with a hammer. A fast-mode
> >> > shutdown seems perfectly adequate. If it isn't, you're going to need
> >> > nontrivial recovery effort anyhow.
> >>
> >> All of this is completely besides the point that a database that's
> >> been shutdown immediately / had the power cord yanked comes back up
> >> and doesn't start autovacuuming automatically, which seems a
> >> non-optimal behaviour.
> >
> > It's also not going to endear us very much to the VLDB crowd - it will
> > amounts to a multi-hour crash recovery for those folks while analyze
> > regenerates statistics.
>
> But this would be AOK behaviour for small transactional databases?
Defiantly not.
> Again, besides the point, but important. The real point is a database
> that doesn't run autovac after an emergency shutdown is broken by
> design, and not just for one use case.
This behaviour is also undocumented AFAIK. I would bet that a lot of
users would have no idea that they are in this state post
crash-recovery.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
