Re: why pg_walfile_name() cannot be executed during recovery?

> 22 апр. 2022 г., в 19:15, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> написал(а):
>
> On Sat, Apr 9, 2022 at 10:21 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Sat, Apr 9, 2022 at 12:25 PM Andrey Borodin <x4mmm(at)yandex-team(dot)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 you are 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)
AFAIK flush, receive and replay LSNs may be on 3 different timelines rendering two names incorrect. Actually, this proves that pg_wal_filename() should not be called on Standby with a present function prototype.

> 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
What kind of reporting?

> or figuring out whether a WAL file exists given an LSN or
> for some other reason.
There might me many WAL files on the same LSN. Please, specify more detailed scenario to use WAL file name.

> 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?

I do not see correct use-case among these. You justify necessity to run pg_wal_filename() on Standby by having a LSN (not a problem), by doing some kind of reporting (to broad problem) and checking existence of some WAL file (more details needed). What is the problem leading to checking the existence of the file?

Thanks!

Best regards, Andrey Borodin.