On Sun, 2007-03-18 at 07:39 -0700, Randy Isbell (jisbell) wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > BTW, the backup process is supposed to result in backup_label being
> > present in the filesystem dump, so that you'd have had to go out of
> > way for it to NOT be present (which is why we didn't think it needed
> > much documentation). What exactly was happening? If you didn't
> > deliberately remove it from the dump, there may still be some kind
> > bug here.
> Correct. backup_label was getting created. My cleanup of such items
> as pg_xlog/ was overly aggressive and removing backup_label. While
> testing with no database activity during the dump, the problem did not
> I'll send verbiage to the docs folks as requested. Thanks again for
> all the help.
Not sure if we ever patched the docs for this one.
This happened again recently.
I would like to introduce a WARNING message into recovery to show that a
backup_label was expected, yet was not present. This is normal in some
use cases of recovery, but we need to be able to tell those situations
apart. Any objections?
Perhaps we can upgrade that to an explicit option in the recovery.conf,
so we have backup_label_required=true as the default, that can be
overridden. But that would break too many existing setups and we should
wait to see how the dust settles on 8.4 before we do that in the future.
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
In response to
pgsql-bugs by date
|Next:||From: hubert depesz lubaczewski||Date: 2008-06-05 08:17:27|
|Subject: Re: BUG #4220: delete statement deleted too many rows|
|Previous:||From: Heikki Linnakangas||Date: 2008-06-05 05:59:04|
|Subject: Re: BUG #4222: ERROR: cache lookup failed for relation|