| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_controldata gobbledygook |
| Date: | 2013-04-26 03:19:14 |
| Message-ID: | 29207.1366946354@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The comments in the pg_control.h header file use much more pleasant
> terms, which when put to use would lead to output similar to this:
> Latest checkpoint's next free transaction ID: 0/7575
> Latest checkpoint's next free OID: 49152
> Latest checkpoint's next free MultiXactId: 7
> Latest checkpoint's next free MultiXact offset: 13
> Latest checkpoint's cluster-wide minimum datfrozenxid: 1265
> Latest checkpoint's database with cluster-wide minimum datfrozenxid: 1
> Latest checkpoint's oldest transaction ID still running: 0
> Latest checkpoint's cluster-wide minimum datminmxid: 1
> Latest checkpoint's database with cluster-wide minimum datminmxid: 1
> One could even rearrange the layout a little bit like this:
> Control data as of latest checkpoint:
> next free transaction ID: 0/7575
> next free OID: 49152
> etc.
> Comments?
I think I've heard of scripts grepping the output of pg_controldata for
this that or the other. Any rewording of the labels would break that.
While I'm not opposed to improving the labels, I would vote against your
second, abbreviated scheme because it would make things ambiguous for
simple grep-based scripts.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2013-04-26 03:19:53 | Re: In progress INSERT wrecks plans on table |
| Previous Message | Peter Eisentraut | 2013-04-26 03:07:02 | pg_controldata gobbledygook |