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
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
>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 su
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/728 when recovery
> target name "2023-10-10 15:07:37" is at 0/
Hello.
We had PostgreSQL v11 and used PITR with our database.
But PITR behavior was changed in v13
>https://www.postgresql.org/docs/release/13.0/
>Generate an error if recovery does not reach the specified recovery target
>(Leif Gunnar Erlandsen, Peter Eisentraut)
>Previously, a standby would pro
