Re: why pg_walfile_name() cannot be executed during recovery? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: why pg_walfile_name() cannot be executed during recovery?
Date
Msg-id CALj2ACXU2uuMgRbYKvWRMFuH4WBYyCqnCudRnbF0HD+nmzp9hw@mail.gmail.com
Whole thread Raw
In response to Re: why pg_walfile_name() cannot be executed during recovery?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: why pg_walfile_name() cannot be executed during recovery?  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On Sat, Apr 9, 2022 at 10:21 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Sat, Apr 9, 2022 at 12:25 PM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> > Please excuse me if I'm not attentive enough. I've read this thread. And I could not find what is the problem that
youare solving. What is the purpose of the WAL file name you want to obtain?
 
>
> Yeah, I'd also like to know this.

IMO, uses of pg_walfile_{name, name_offset} are plenty. Say, I have
LSNs (say, flush, insert, replayed or WAL receiver latest received)
and I would like to know the WAL file name and offset in an app
connecting to postgres or a control plane either for doing some
reporting or figuring out whether a WAL file exists given an LSN or
for some other reason. With these functions restricted when the server
is in recovery mode, the apps or control plane code can't use them and
they have to do if (!pg_is_in_recovery()) {select * from
pg_walfile_{name, name_offset}.

Am I missing any other important use-cases?

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Dump/Restore of non-default PKs
Next
From: Peter Eisentraut
Date:
Subject: Re: Fix NULL pointer reference in _outPathTarget()