Re: Safely Killing Backends

My point/question is: when I've seen this before and recovery mode is
taking on the order of minutes, I find that doing:

pg_ctl stop -m i
pg_ctl start

is faster (on the order of seconds) than letting postgres finish
recovery mode. So I wonder:

1. Is this safe from a data integrity point of view?
2. Why is it faster?

Maybe the difference in time I've experienced is partially a result of
the number of connections that come in (via PHP) during recovery mode,
so recovering takes longer because the database is still in multi-user
mode and receiving connections even if not fulfulling requests?

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Feb 8, 2005, at 2:57 PM, Vivek Khera wrote:

> TFO> Which brings up a follow-up question: is it documented anywhere
> TFO> exactly what goes on in recovery mode? If so, I've not found it.
>
> TFO> When I've experienced this, it has seemed quicker just to stop and
> TFO> restart postgres than to let recovery mode complete. Is that
> unsafe?
>
> The recovery has to happen at some point.  What it is doing is
> bringing your DB to a known valid state based on the committed
> transactions, what's written to disk, and what's written to the
> pg_xlog files.  A vacuum is probably in good order after this happens.
>
> Effectively, it does the moral equivalent of unplugging the power cord
> and restarting itself, without the bother of needing to reboot the
> whole machine :-)