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

From Ron
Subject Re: A question about possible recovery inconsistency
Date
Msg-id 199ffa21-3fa9-83e6-e62d-40eaee6fbfd8@gmail.com
Whole thread Raw
In response to Re: A question about possible recovery inconsistency  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-general
On 10/11/23 12:07, Ron wrote:
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


After that pg_basebackup, do this to get R/W copy of the database:
pg_ctl start
pg_ctl promote

--
Born in Arizona, moved to Babylonia.

pgsql-general by date:

Previous
From: Ron
Date:
Subject: Re: Assitance needed for the resolution of memory leak
Next
From: Atul Kumar
Date:
Subject: logs are not getting logged in error logs