Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2004-11-06 at 23:29, Tom Lane wrote:
>> A possibly more reliable interlock would involve having the postmaster
>> probe during normal startup to see if there is already an archived WAL
>> segment for what it thinks is the current segment.
> Yes, ch
On Sat, 2004-11-06 at 23:29, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > If a further pg_ctl mode, recover, were implemented, this would allow a
> > fail safe mode for recovery.
>
> > e.g.pg_ctl -D datadir recover
>
> > pg_ctl could then check for the existence of a reco
On Sun, 2004-11-07 at 00:54, Mark Kirkwood wrote:
> While this is nice, it will not help you if the restoration directory is
> different from your archive directory. That is : restore_command in
> recovery.conf fetches from somewhere other than where archive_command in
> postgresql.conf copied.
On Sun, 2004-11-07 at 00:16, Tom Lane wrote:
> I wrote:
> > A possibly more reliable interlock would involve having the postmaster
> > probe during normal startup to see if there is already an archived WAL
> > segment for what it thinks is the current segment.
>
> Another and simpler way is to rec
I was thinking that even mildly experienced folks could benefit from a
helpful sanity check. Typically the need to recover a system never comes
at a good time, and features that help prevent silly mistakes are a
great stress saver.
As an aside, while testing recovery during pre beta, I think I
While this is nice, it will not help you if the restoration directory is
different from your archive directory. That is : restore_command in
recovery.conf fetches from somewhere other than where archive_command in
postgresql.conf copied.
I am not sure how likely this situation is, but setting u
I wrote:
> A possibly more reliable interlock would involve having the postmaster
> probe during normal startup to see if there is already an archived WAL
> segment for what it thinks is the current segment.
Another and simpler way is to recommend that people use archive_command
strings that won't
I like it - nice and simple, but targets a large (and likely) foot gun
situation.
regards
Mark
Simon Riggs wrote:
If a further pg_ctl mode, recover, were implemented, this would allow a
fail safe mode for recovery.
e.g.pg_ctl -D datadir recover
pg_ctl could then check for the existence of a r
Simon Riggs <[EMAIL PROTECTED]> writes:
> If a further pg_ctl mode, recover, were implemented, this would allow a
> fail safe mode for recovery.
> e.g. pg_ctl -D datadir recover
> pg_ctl could then check for the existence of a recovery.conf file and
> return an error if none were found.
I can't
Joachim Wieland has diligently and sensibly pointed out a potential for
user error with the current PITR implementation. This is not a bug *per
se*, but is a design flaw that more than one person could fall into. It
is a minor issue and not that likely, since the manual describes what to
do...but
10 matches
Mail list logo
