Re: why pg_walfile_name() cannot be executed during recovery?
От | Robert Haas |
---|---|
Тема | Re: why pg_walfile_name() cannot be executed during recovery? |
Дата | |
Msg-id | CA+TgmoYvpV0i0F=ogneQy+2RRd0UONQFCHPU_qc6GQUMdqry8A@mail.gmail.com обсуждение исходный текст |
Ответ на | why pg_walfile_name() cannot be executed during recovery? (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>) |
Ответы |
Re: why pg_walfile_name() cannot be executed during recovery?
Re: why pg_walfile_name() cannot be executed during recovery? |
Список | pgsql-hackers |
On Fri, Apr 2, 2021 at 4:23 AM SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> wrote: > Why pg_walfile_name() can't be executed under recovery? I believe the issue is that the backend executing the function might not have an accurate idea about which TLI to use. But I don't understand why we can't find some solution to that problem. > What is the best way for me to get the current timeline and/or the file being recovering on the standby using a postgresquery? I know I can get it via process title but don't want to go that route. pg_stat_wal_receiver has LSN and TLI information, but probably won't help except when WAL receiver is actually active. pg_last_wal_receive_lsn() and pg_last_wal_replay_lsn() will give the LSN at any point during recovery, but not the TLI. We might have some gaps in this area... -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: