Re: Cluster name in ps output

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2014-05-05 10:00:34 +0000, Thomas Munro wrote:
> > When running more than one cluster I often find myself looking at
> > the output of 'iotop' or other tools wondering which
> > cluster's "wal receiver process" or "checkpointer process" etc
> > I'm seeing.
>
> I wonder about that pretty regularly. To the point that I've a hacky
> version of this locally. So +1 for me for the idea in general.

Ditto.

> > If cluster_name is not set, it defaults to the empty string and
> > the ps output is unchanged. If it's set to 'foox' the ps output
> > includes that string in square brackets:
> >
> > postgres: [foox] checkpointer process
> > postgres: [foox] writer process
> > postgres: [foox] wal writer process
> > postgres: [foox] autovacuum launcher process
> > postgres: [foox] stats collector process
> > postgres: [foox] munro foodb [local] idle
>
> "postgres: [foox] ..." should rather be "postgres[foox]: ..." imo ;)
>
> I guess the question is where this should be available as well. At the
> very least I'd want to reference it in log_line_prefix as well?

I'm not entirely sure that I see the point of having it in
log_line_prefix- each cluster logs to its own log file which includes
the cluster name (at least on Debian/Ubuntu and friends). The only use
case I can imagine here would be for syslog, but you could just *set*
the cluster name in the log_line_prefix, as it'd be (by definition..)
configurable per cluster.

I'd much rather see other things added as log_line_prefix options.. An
interesting thought that just occured to me would be to allow any GUC to
be added to log_line_prefix using some kind of extended % support (eg:
'%{my_guc_here}' or something...). Would also be useful for extensions
which add GUCs then? Not sure about specifics, but does seem like an
interesting idea.

Oh, and I know people will shoot me for bringing it up again, but I'd
still like to see the CSV format be configurable ala log_line_prefix,
and the same for any kind of logging (or auditing) to a table which we
might eventually support. Yes, we need to work out how to do file
changes when it's updated and stick a header on each new file with the
columns included.

Thanks,

Stephen