Re: Problem with PITR recovery

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Archive on stop is right out.  The common reason for a stop is that the
> >> system is being shut down, and we don't have time to archive a WAL file
> >> before init will kill -9 us.
> 
> > Ah, good point.  Can we do it for 'smart' shutdown mode, which is the
> > default?  I see server stop scripts using 'fast' where we would not do
> > the WAL archive.
> 
> [ thinks about it... ]  Yeah, that seems doable, since 'smart' mode by
> definition isn't making any promises about getting out of town quick.
> 
> However, would it really be all that helpful to do that?  I'm not sure
> I trust a backup methodology that depends on having shut down the server
> in "the right way".
> 
> It seems reasonable to me to have pg_stop_backup() close the current WAL
> segment, and also to have some time-limit-driven mechanism for doing so.
> What's the use-case for doing it on postmaster stop, though?

I am thinking someone runs a tar backup at night, shuts down the server
the next day, and goes to recover to a new machine.  Wouldn't they think
the shutdown server had flushed all its archive logs?  I would.

I guess I would expect some kind of sanity in how the logs are kept. 
Our current "keep the last one active" is a pretty strange user
interface and I think a shutdown server should give a resonable API, and
I think that includes flushing logs.  In fact, considering we would have
a timer, you could argue that a shutdown could be down for a very long
time and flushing the archive logs would make sense.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073