Re: A question about possible recovery inconsistency - Mailing list pgsql-general

From Ron
Subject Re: A question about possible recovery inconsistency
Date
Msg-id dcb6d46e-0389-db66-ba5e-0e4a3ab13498@gmail.com
Whole thread Raw
In response to Re: A question about possible recovery inconsistency  (Eugen Konkov <ekonkov@planitar.com>)
Responses Re: A question about possible recovery inconsistency  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-general
On 10/11/23 09:52, Eugen Konkov wrote:
But why do you want to do that, if all that you have to do is specify
"recovery_target = 'immediate'" to recover to the end of the backup?

Because automation scripts do not know if transactions are available
after some point in time or not. But automation scripts know that
backup was completed successfully at that point.
For example:
We want to provide time to recover the database.
1. Base backup restored, wal files are applied successfully if there
is a transaction.

Doesn't "pg_basebackup --wal-method=stream" already do that?

Since the commands below automagically starts physical streaming, there must be a variation where all the wal data is applied but doesn't start replication.

pg_basebackup --dbname=service=basebackup -D $PGDATA --progress --checkpoint=fast -v \
        --write-recovery-conf --wal-method=stream --create-slot --slot=pgstandby1 --compress=server-zstd
pg_ctl start -w

Maybe just remove the two "slot" options:
pg_basebackup --dbname=service=basebackup -D $PGDATA --progress --checkpoint=fast -v \
        --write-recovery-conf --wal-method=stream --compress=server-zstd

--
Born in Arizona, moved to Babylonia.

pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: log wal file transfer in error logs
Next
From: Atul Kumar
Date:
Subject: Re: log wal file transfer in error logs