Re: Fetching timeline during recovery - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fetching timeline during recovery
Date
Msg-id 20200131061230.GE2631@paquier.xyz
Whole thread Raw
In response to Re: Fetching timeline during recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Responses Re: Fetching timeline during recovery  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
List pgsql-hackers
On Thu, Jan 23, 2020 at 05:54:08PM +0100, Jehan-Guillaume de Rorthais wrote:
> Please find the new version of the patch in attachment.

To be honest, I find the concept of this patch confusing.
pg_stat_wal_receiver is just a one-one mapping with the shared memory
state of the WAL receiver itself and show data *if and only if* a WAL
receiver is running and iff it is ready to display any data, so I'd
rather not change its nature and it has nothing to do with the state
of WAL being applied by the startup process.  So this gets a -1 from
me.

-   /*
-    * No WAL receiver (or not ready yet), just return a tuple with NULL
-    * values
-    */
-   if (pid == 0 || !ready_to_display)
-       PG_RETURN_NULL();
Note that this took a couple of attempts to get right, so I'd rather
not change this part of the logic on security grounds.

Isn't what you are looking for here a different system view which maps
directly to XLogCtl so as you can retrieve the status of the applied
WAL at recovery anytime, say pg_stat_recovery?

It is the end of the CF, I am marking this patch as returned with
feedback for now.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Unix-domain socket support on Windows
Next
From: Masahiko Sawada
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)