Re: kill -KILL: What happens?

On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I strongly believe you're in the minority on that one, for the same
>> reasons that I don't think most people would agree with your notion of
>> what should be the default shutdown mode.  A database that can't
>> accept new connections is a liability, not an asset.
>
> Killing active sessions when it's not absolutely necessary is not an
> asset.

That's a highly arguable point and I certainly don't agree with it. A
database with no postmaster and no background processes can't possibly
be expected to function in any sort of halfway reasonable way. In
particular:

1. No checkpoints will occur, so the time required for recovery will
grow longer without bound.
2. All walsenders will exit, so no transactions will be replicated to standbys.
3. Transactions committed asynchronously won't be flushed to disk, and
are lost entirely unless enough other WAL activity occurs before the
last backend dies to force a WAL write.
4. Autovacuum won't run until the system is properly restarted, and to
make matters worse there's no statistics collector, so the information
that might trigger a later run will be lost also.
5. At some point, you'll run out of clean buffers, after which
performance will start to suck as backends have to do their own
writes.
6. At some probably later point, the fsync request queue will fill up,
after which performance will go into the toilet. On 9.1devel, this
takes less than a minute of moderate activity on my MacOS X machine.

All in all, running for any significant period of time in this state
is likely a recipe for disaster, even if for some inexplicable reason
you don't care about the fact that the system won't accept any new
connections.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company