Re: pg_system_identifier()

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_system_identifier()
Date: 2013-08-26 20:50:09
Message-ID: 20130826205009.GD5464@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-08-26 16:35:57 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2013-08-26 10:10:54 -0700, Josh Berkus wrote:
> >> I'm going to reverse my vote, and vote against this patch. The reason
> >> why is that I think we should instead have a function:
> >>
> >> pg_controldata(parameter text)
> >>
> >> ... which would report *all* strings in pg_controldata. Hence, you'd do
> >> instead:
> >>
> >> pg_controldata('system identifier')
> >>
> >> This will hopefully spare us from 15 patches incrementally adding all of
> >> the individual items in controldata.
>
> > If anything but the proposed feature, it should be an SRF - passing in
> > text parameters isn't very discoverable.
>
> I'm not pleased with the idea that we'd have to dumb all the relevant
> datatypes down to text so that we could push them through this single
> function.

We came to the same conclusion in an IM discussion some minutes
ago. There doesn't seem much to be going for anything but plain
functions that expose a single value each. a) greppability b)
discoverability c) data types.

The interesting data points around pg_control we could think of were:
* system identifier (text pg_system_identifier())
* current timeline id (bigint? pg_current_timeline())
* last checkpoint time (timestamptz pg_last_checkpoint_timestamp())
* last checkpoint location (text pg_last_checkpoint_location())

Those might also be interesting, but I am not 100% sure:
* minimum recovery point (text pg_minimum_recovery_location())
* minimum recovery timeline (bigint? pg_minimum_recovery_timeline())
* backup starting point (text pg_backup_start_location())
* backup end point (text pg_backup_end_location())
* backup end required? (bool pg_backup_end_required())

All the other variables are either already exposed, don't seem to be all
that interesting or not necessary accurate for a running cluster.

I'd vote for doing things piecemal here, otherwise it seems to be too
likely that we never get anywhere.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-08-26 21:25:49 Re: pg_system_identifier()
Previous Message Tom Lane 2013-08-26 20:35:57 Re: pg_system_identifier()