Re: pg_system_identifier() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_system_identifier()
Date
Msg-id 20130826205009.GD5464@awork2.anarazel.de
Whole thread Raw
In response to Re: pg_system_identifier()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2013-08-26 16:35:57 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_system_identifier()
Next
From: Josh Berkus
Date:
Subject: Re: pg_system_identifier()