From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: trivial patch for dynahash logging |
Date: | 2014-09-27 22:09:05 |
Message-ID: | 9208.1411855745@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> under HASH_STATISTICS, the output reporting "this HTAB" upon destruction is
> pretty useless. Which HTAB would this one be? It is not necessarily the
> most recently created one.
> This makes it output the %p to the actual HTAB, so it can be matched up
> with the logging of the creation.
Seems reasonable, although I wonder why neither of them print the tabname
string. More generally, I see no calls to hash_stats() anywhere except
in hash_destroy(), so wouldn't you need a rather larger patch to make it
actually do anything useful?
> I'm not sure why it bypasses elog. Is that so it can run during start-up
> before elog is active? I'd like to make it go through elog so that
> log_line_prefix are applied, but then it would no longer be a trivial patch.
A quick dig in our git history shows that it was like that in Postgres95,
so the answer is most likely "this code predates elog()". I would think
it'd be a safe assumption that elog is initialized before any hashtables
are created, but certainly you could test that pretty quickly ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-09-27 22:23:57 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Previous Message | Jeff Janes | 2014-09-27 21:43:51 | trivial patch for dynahash logging |