Re: Problem with PITR recovery

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073