On 09/11/2014 12:22 PM, Andres Freund wrote:
On 2014-09-11 12:14:42 +0300, Heikki Linnakangas wrote:
On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.com wrote:
I think the names that rm_identify returns should match those that the
rm_desc functions print.
I had originally started off trying to keep the output in sync, but it
doesn't work very well. There are rm_desc functions that print things
like "truncate before" and "Create posting tree", and many decisions
are quite arbitrary ("freeze_page", "cleanup info", "multi-insert").
It would be good to clean up those messages to be more sensible and
consistent.
I think it's better the (grep-friendly) way it is. If anything, perhaps
rm_desc should output "${rm_identify}[: optional explanation]". That
would also make it very clear what should go in rm_identify and what
should go in rm_desc.
Yeah, that makes sense too.
I'm not sure I agree here. From a theoretical POV sure, but wouldn't
that lead to even longer lines for xlogdump and other error messages for
some records?
No. All the rm_desc functions already follow that convention, and print
"foo: details", where "foo" identifies the record type based on xl_info.
This proposal would just make that convention more official, and
stipulate that the "foo" part should match what the new rm_identify()
function returns. (Or perhaps even better, define it so that rm_desc
prints only the "details" part, and rm_identify() the "foo" part, and
have the callers put the two strings together if they want)
There are similar cases in B-tree splits, for
example, where a split where the new tuple goes to the left half is
considered a different record type than one where it goes ot the right half.
It might be interesting to count them separately in the stats, but then
again it might just be confusing. The xl_info flags and the rm_desc output
were never intended to be a useful categorization for statistics purposes,
so it's not surprising that it's not too well suited for that. Nevertheless,
the "pg_xlogdump --stats" is useful as it is, if you know the limitations.
I agree it's not perfect, but I think it's a huge step forward. We very
well might want to improve upon the stats granularity once in, but I
think it already gives a fair amount of direction where to look.
Agreed. That's what I was also trying to say.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
