Re: autovacuum and immediate shutdown issues
От | Brad Nicholson |
---|---|
Тема | Re: autovacuum and immediate shutdown issues |
Дата | |
Msg-id | 1255969846.4316.43.camel@bnicholson-desktop обсуждение исходный текст |
Ответ на | Re: autovacuum and immediate shutdown issues (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: autovacuum and immediate shutdown issues
|
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: