From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #3110: Online Backup introduces Duplicate OIDs |
Date: | 2008-06-05 17:28:26 |
Message-ID: | 1212686906.19964.187.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 2008-06-05 at 11:39 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > * In the release note comments, add that in a future release we will add
> > a parameter to recovery.conf "require_backup_label" which defaults to
> > "true".
>
> The problem that I'm having with that idea is that it breaks
> crash-recovery after replay starts, because we intentionally remove the
> backup label once we've read it. (And no, please do not suggest
> rewriting the config file ...)
LOL :-)
Hmm, seems we can check for the backup_label.old if the first check
fails. We don't actually remove the backup_label, we just move it out of
the way.
> Basically it seems that we need a more robust way to distinguish
> "beginning a recovery" from "resuming a recovery". Perhaps more state
> in pg_control is needed?
That would work also.
Which do you prefer? The former is back patchable eventually, the latter
is not, even if I like it as a cleaner solution.
Or should we just go with shouting DON'T REMOVE THE backup_label FILE in
the docs?
For that matter, it would be easier to list the files you *are* allowed
to remove *ever* somewhere prominent and leave it at that, rather than
try to explain all the various ways the other files are essential.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Lawrence Cohan | 2008-06-05 18:15:29 | BUG #4224: issue with LIMIT and ORDER BY |
Previous Message | Nathan Reed | 2008-06-05 17:22:44 | Re: BUG #4219: fseeko test failure in configure script |