From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | laurenz(dot)albe(at)wien(dot)gv(dot)at ("Albe Laurenz"), "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: backup_label in a crash recovery |
Date: | 2009-11-03 16:01:09 |
Message-ID: | 5091.1257264069@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[ after further thought... ]
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> How do you distinguish between these two scenarios:
> 1) you're starting up in a data dir where you crashed in the middle of
> a backup
> 2) you're starting up in a data dir that is a restore of a base backup,
> but no recovery.conf has been created
> (hint: you can't)
Hmm ... you can not tell this if the postmaster just started, and
I agree that removing backup_label in such a case is too risky.
However, in a typical crash scenario the postmaster doesn't die,
it just kills off and restarts its children; and in that scenario
we do have additional knowledge, namely that the postmaster was
already up. I think it could be safe and useful to forcibly remove
backup_label before commencing recovery, *if* we know that the system
had previously been in fully-operational status.
However, this begs the question: does a backend crash necessarily imply
that an in-progress base backup has to be canceled and restarted from
scratch? It's not clear to me why you wouldn't consider that the backup
can keep going. So maybe what we really want here is not to remove the
label file, but to have the postmaster signal to the recovery process
that it knows this is a crash recovery and any backup_label should be
ignored.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-11-03 16:01:14 | Re: EOL for 7.4? |
Previous Message | Kevin Grittner | 2009-11-03 15:53:10 | Re: A small bug in gram.y |