Re: Cluster name in ps output
| От | Thomas Munro |
|---|---|
| Тема | Re: Cluster name in ps output |
| Дата | |
| Msg-id | CADLWmXUqsNxM0rmqzZ4tbcJmsnKN5Cu4SmgRk-bfgmRV-R3vdg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Cluster name in ps output (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Cluster name in ps output
Re: Cluster name in ps output |
| Список | pgsql-hackers |
On 5 May 2014 10:10, Andres Freund <andres@2ndquadrant.com> wrote:
Thanks! (Do you have a write up/diff somewhere showing the local modifications you're running?)
Hmm -- I thought the GUC machinery would make sure cluster_name either pointed to the default I provided, an empty string, or a string read from the configuration file. Perhaps I need to go and read up on how GUCs work.
Thomas Munro
Hi,I wonder about that pretty regularly. To the point that I've a hacky
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.
version of this locally. So +1 for me for the idea in general.
Thanks! (Do you have a write up/diff somewhere showing the local modifications you're running?)
> If cluster_name is not set, it defaults to the empty string and"postgres: [foox] ..." should rather be "postgres[foox]: ..." imo ;)
> 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
Hah -- I agree, but on systems using setproctitle, the program name and ": " are provided already, so the end result would have to be different on those systems and I figured it should be the same everywhere if possible. (BTW I also tried to tidy up the way that is handled, so that instead of a different snprintf statement being selected by the preprocessor, a macro PROGRAM_NAME_PREFIX is defined to be empty on those systems).
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?
Good idea, I will look into that.
> + if (*cluster_name == '\0')
> + {
> + snprintf(ps_buffer, ps_buffer_size,
> + PROGRAM_NAME_PREFIX "%s %s %s ",
> + username, dbname, host_info);
> + }
> + else
> + {
> + snprintf(ps_buffer, ps_buffer_size,
> + PROGRAM_NAME_PREFIX "[%s] %s %s %s ",
> + cluster_name, username, dbname, host_info);
> + }
> +
> ps_buffer_cur_len = ps_buffer_fixed_size = strlen(ps_buffer);
Aren't you potentially dereferencing a NULL pointer here?
Hmm -- I thought the GUC machinery would make sure cluster_name either pointed to the default I provided, an empty string, or a string read from the configuration file. Perhaps I need to go and read up on how GUCs work.
Thomas Munro
В списке pgsql-hackers по дате отправления: