Re: Compilation issues for HASH_STATISTICS and HASH_DEBUG options

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> Yeah. Just to aid discussion, let's say the attached patch.

I think if we want to claim that these bits represent actually
usable functionality, we need to do more than s/fprintf/elog/.
Some points:

* Neither printout identifies which hashtable it's talking about
in any usable fashion, which is silly when we could print
hashp->tabname. HASH_DEBUG prints the pointer to the table,
which is certainly useless unless you've got gdb attached to
the session, and probably useless even then without the tabname.

* The output formats are randomly inconsistent with each other,
and don't look much like other outputs either. I'm particularly
vexed by the fact that you could not usefully grep the log for
this data. I think we should switch them to a single log line so
that grepping for a hashtable name could produce something useful.

* As it stands, HASH_DEBUG prints only at hashtable creation and
HASH_STATISTICS prints only at table destruction. Is that really
enough? I'm thinking in particular of shared and session-lifespan
hashtables, which won't ever receive a hash_destroy call.

* One fairly believable use-case for hash_stats() is to be called
manually from a debugger. To make that a little easier, I think
we should fix it to not crash if "where" is NULL.

> I don't really have an idea on which debug level these should appear
> on, however. I picked DEBUG4 for no other reason than DEBUG5 being
> quite verbose with AIO related messages.

No opinion here either.

regards, tom lane