Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with PITR recovery
Date
Msg-id 24007.1113845937@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Assigning fixed OIDs to system catalogs and indexes
Next
From: Bruce Momjian
Date:
Subject: Re: Problem with PITR recovery