Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, arorasam(at)gmail(dot)com
Subject: Re: add retry mechanism for achieving recovery target before emitting FATA error "recovery ended before configured recovery target was reached"
Date: 2021-10-23 18:54:53
Message-ID: 4119dbc92c0acd80f38354246205c25745c80eac.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2021-10-23 at 09:31 +0530, Bharath Rupireddy wrote:
> If you are suggesting ...

Your complaint seems to be coming from commit dc788668, so the most
direct answer would be to make that configurable to the old behavior,
not to invent a new timeout behavior.

If I understand correctly, you are doing PITR from an archive, right?
So would restore_command be a reasonable place for the timeout?

And can you provide some approximate numbers to help me understand
where the timeout would be helpful? E.g. you have W GB of WAL to
replay, and restore would take X minutes, but some WAL is missing so
you fail after X-Y minutes, but if you has timeout Z everything would
be great.

> I think pg_waldump can help here to do some exploratory analysis of
> the available WAL in the directory where the WAL files are present.
> Since it is an independent C program, it can run even when the server
> is down and also run on archive location.

Right, it's possible to do, but I think there's room for improvement so
we don't have to always scan the WAL. I'm getting a bit off-topic from
your proposal though. I'll bring it up in another thread when my
thoughts on this are more clear.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikhail 2021-10-23 19:02:16 Re: [PATCH] Make ENOSPC not fatal in semaphore creation
Previous Message Bharath Rupireddy 2021-10-23 17:40:09 Re: logical decoding/replication: new functions pg_ls_logicaldir and pg_ls_replslotdir