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

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