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

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why pg_walfile_name() cannot be executed during recovery?
Date: 2022-04-09 16:25:01
Message-ID: A7002722-492F-44F9-9AEE-DA031C443307@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 9 Apr 2022, at 18:30, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Using insert tli when not in recovery and using tli of the last WAL
> replayed record in crash/archive/standby recovery, seems a reasonable
> choice to me.

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?

pg_walfile_name() - is a formatting function. With TLI as an hidden argument. If we want it to work on Standby we should just convert it to pure formatting function without access the the DB state, pass TLI as an argument.
Making implicit TLI computation with certain expectations is not a good idea IMV.

pg_walfile_name() could just read .history file, determine which TLI contains given LSN and format the name. And still there's a tricky segments during TLI switch.

Either way we can rename the function to pg_walfile_name_as_if_on_timeline_of_last_wal_replayed().

Thanks!

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-04-09 16:27:12 Re: How about a psql backslash command to show GUCs?
Previous Message Jonathan S. Katz 2022-04-09 16:14:20 Re: How about a psql backslash command to show GUCs?