Re: Fetching timeline during recovery

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, masao(dot)fujii(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fetching timeline during recovery
Date: 2020-01-31 06:12:30
Message-ID: 20200131061230.GE2631@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-01-31 06:21:07 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Previous Message Craig Ringer 2020-01-31 06:10:41 Re: Unix-domain socket support on Windows