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

From Laurenz Albe
Subject Re: A question about possible recovery inconsistency
Date
Msg-id 386a5cbfb38a6cd0c5fd5ed7f0d08154c2cdb49b.camel@cybertec.at
Whole thread Raw
In response to A question about possible recovery inconsistency  (Eugen Konkov <ekonkov@planitar.com>)
Responses Re: A question about possible recovery inconsistency
List pgsql-general
On Tue, 2023-10-10 at 11:46 -0400, Eugen Konkov wrote:
> [wants to avoid
>  FATAL:  recovery ended before configured recovery target was reached
>  that is issued in v13 and later]
>
> 1. Why here (in experiment2.txt) redo done at 0/7000028 when recovery
> target name "2023-10-10 15:07:37" is at 0/7000090?
> I suppose 0/7000090 should be included, because
> `recovery_target_inclusive=true` by default.

Because there was no transaction at 0/7000090.

> 2. Is there any way to include a label into a base backup which I can
> use as `recoverty_target_name`?
> This is not clear from documentation
> https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP
> Is 'label' the name for `recovery_target_name` /
> `pg_create_restore_point` is called by `pg_backup_start`?

No.

> 3. Is there any way to get the latest time from a base backup which is
> reachable and could be used as the value for `recovery_target_time`?
> As a workaround for XX000 error I inserted one additional record into
> the database, so a new WAL file is generated. Then I can use the t3
> value for `recovery_target_time`.
> This only works when archive_command/restore_command was configured.
> But without them it seems I can not use the `recovery_target_time`
> option. Is this true?

Perhaps you could use the time from the "backup" file in the WAL archive,
not sure.

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?

Yours,
Laurenz Albe



pgsql-general by date:

Previous
From: Israr Khan
Date:
Subject: Subject: FATAL: cache lookup failed for relation 1247
Next
From: Олег Самойлов
Date:
Subject: Can not drop partition if exist foreign keys