Re: pg_system_identifier()
От | Andres Freund |
---|---|
Тема | Re: pg_system_identifier() |
Дата | |
Msg-id | 20130826205009.GD5464@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_system_identifier() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: