| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Rob Butler <crodster2k(at)yahoo(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Jeff Davis <jdavis-pgsql(at)empires(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Problem with PITR recovery |
| Date: | 2005-04-18 17:38:57 |
| Message-ID: | 24007.1113845937@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-04-18 17:41:16 | Re: Problem with PITR recovery |
| Previous Message | Bruce Momjian | 2005-04-18 17:24:21 | Re: Assigning fixed OIDs to system catalogs and indexes |