Re: Fetching timeline during recovery

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: Fetching timeline during recovery
Date: 2019-12-11 15:24:42
Message-ID: 20191211152442.GB1942@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 11, 2019 at 10:16:29AM -0500, Stephen Frost wrote:
> I've not followed this discussion very closely but I agree entirely that
> it's really nice to have the timeline be able to be queried in a more
> timely manner than asking through pg_control_checkpoint() gives you.
>
> I'm not sure about adding a text argument to such a function though, I
> would think you'd either have multiple rows if it's an SRF that gives
> you the information on each row and allows a user to filter with a WHERE
> clause, or do something like what pg_stat_replication has and just have
> a bunch of columns.

With a NULL added for the values which cannot be defined then, like
trying to use the function on a primary for the fields which can only
show up at recovery? That would be possible, still my heart tells me
that a function returning one row is a more natural approach for
this stuff. I may be under too much used to what we have in the TAP
tests though.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-11 15:33:53 Re: error context for vacuum to include block number
Previous Message Stephen Frost 2019-12-11 15:19:08 Re: [Proposal] Level4 Warnings show many shadow vars