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