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