Cluster name in ps output

Hi,

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.

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?

diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 15020c4..7f7fd52 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -449,6 +449,7 @@ int			temp_file_limit = -1;

int num_temp_buffers = 1024;

+char *cluster_name;
char *data_directory;
char *ConfigFileName;
char *HbaFileName;
@@ -3091,6 +3092,17 @@ static struct config_string ConfigureNamesString[] =
},

{
+		{"cluster_name", PGC_POSTMASTER, CUSTOM_OPTIONS,
+			gettext_noop("Sets the name of the cluster that appears in 'ps' output."),
+			NULL,
+			GUC_IS_NAME
+		},
+		&cluster_name,
+		"",
+		NULL, NULL, NULL
+	},
+
+	{
{"data_directory", PGC_POSTMASTER, FILE_LOCATIONS,
gettext_noop("Sets the server's data directory."),
NULL,
diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c
index 6294ca3..ead7ea4 100644
--- a/src/backend/utils/misc/ps_status.c
+++ b/src/backend/utils/misc/ps_status.c
@@ -29,6 +29,7 @@
#include "libpq/libpq.h"
#include "miscadmin.h"
#include "utils/ps_status.h"
+#include "utils/guc.h"

extern char **environ;
bool		update_process_title = true;
@@ -264,15 +265,24 @@ init_ps_display(const char *username, const char *dbname,
* apparently setproctitle() already adds a `progname:' prefix to the ps
* line
*/
-	snprintf(ps_buffer, ps_buffer_size,
-			 "%s %s %s ",
-			 username, dbname, host_info);
+#define PROGRAM_NAME_PREFIX ""
#else
-	snprintf(ps_buffer, ps_buffer_size,
-			 "postgres: %s %s %s ",
-			 username, dbname, host_info);
+#define PROGRAM_NAME_PREFIX "postgres: "
#endif

+	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?

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 5 May 2014 10:10, Andres Freund <andres@2ndquadrant.com> wrote:

Hi,

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.

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
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 ;)

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

On 05/05/2014 06:00 PM, Thomas Munro wrote:

Hi

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. Obviously it's easy enough to find out (for example
by looking at a tree view in htop/ps that shows the -D parameter
of the parent postmaster), but I thought it could be useful to be
able to give a name to the cluster and include it in the ps
output. Here is a strawman patch that does that.

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

I'd find something like that very useful.

I'd even be tempted to tack on the port number, though that might be
overkill.

Perhaps just use the port number instead of a new cluster name? Most
people won't use/set something like a cluster name, though I guess
distros that use pg_wrapper would probably auto-set it via pg_wrapper's
configuration.

Personally I'd find:

postgres[5433]: checkpointer process

at least as useful. The only time that's not unique is in a BSD jail or
lxc container, and in those cases IIRC ps can show you the
jail/container anyway.

Showing the port would help new-ish users a lot; many seem to be very
confused by which PostgreSQL instance(s) they're connecting to and which
are running. Especially on Mac OS X, where people often land up with
Apple's PostgreSQL, Homebrew, Postgres.app, and who knows what else
running at the same time.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-05-05 10:49:19 +0000, Thomas Munro wrote:

On 5 May 2014 10:10, Andres Freund <andres@2ndquadrant.com> wrote:

Hi,

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.

Thanks! (Do you have a write up/diff somewhere showing the local
modifications you're running?)

I've just hacked in the port into the ps display since that was
sufficient for my case.

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 ;)

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.

Fair point.

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.

That's true - but I am not sure you can guarantee it's only called after
the GUC machinery has started up. Particularly on windows. I guess just
initializing the global variable to "" should do the trick.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Andres Freund (andres@2ndquadrant.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

Craig,

* Craig Ringer (craig@2ndquadrant.com) wrote:

postgres[5433]: checkpointer process

at least as useful. The only time that's not unique is in a BSD jail or
lxc container, and in those cases IIRC ps can show you the
jail/container anyway.

Uhh, that's not at all true. You can trivially have multiple IPs on a
box w/o jails or containers (aliased interfaces) and then run PG on the
default port- which I find to be *far* more convenient than having the
same IP and a bunch of different ports.

What you *can't* have is two clusters with the same name and same major
version, at least on the Debian/Ubuntu distributions, and as such, I
would argue to also include the major version rather than include the
port, which you could get from pg_lsclusters.

Showing the port would help new-ish users a lot; many seem to be very
confused by which PostgreSQL instance(s) they're connecting to and which
are running. Especially on Mac OS X, where people often land up with
Apple's PostgreSQL, Homebrew, Postgres.app, and who knows what else
running at the same time.

I'm far from convinced that showing the port in the ps output will
really help these users.. Not to mention that you can get that from
'netstat -anp' anyway.

Thanks,

Stephen

On 2014-05-05 07:58:30 -0400, Stephen Frost wrote:

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.

So I've to configure it in multiple locations? I don't see the point. I
usually try to configure as much in common/template config files that
are included. Everything that doesn't have to be overwritten is good.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2014-05-05 07:58:30 -0400, Stephen Frost wrote:

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.

So I've to configure it in multiple locations? I don't see the point. I
usually try to configure as much in common/template config files that
are included. Everything that doesn't have to be overwritten is good.

I see the point- we've already got quite a few %whatever's and adding
mostly useless ones may just add confusion and unnecessary complexity.
If you've already got your postgresql.conf templated through
puppet/chef/salt/whatever then having to add another '%{ CLUSTER_NAME }%'
or whatever shouldn't be a terribly difficult thing.

Thanks,

Stephen

On 5 May 2014 10:49, Thomas Munro <munro@ip9.org> wrote:

On 5 May 2014 10:10, Andres Freund <andres@2ndquadrant.com> wrote:

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.

See v2 patch attached which lets you use %C for cluster name in the log
prefix.

Maybe it would be overkill, but seeing the various responses about which
information belongs in the ps string, I guess we could also use a format
string with %blah fields for that. Then the Debian/Ubuntu package users
who tend to think of the major version + name as the complete cluster
identifier could use "[%V/%C] ..." to get "postgres: [9.3/main] ...", and
others could throw in a "%P" to see a port number.

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-05-05 10:49:19 +0000, Thomas Munro wrote:

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.

Fair point.

How about dropping the brackets, and the cluster-name concept, and
just doing

postgres: 5432 checkpointer process

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.

That's true - but I am not sure you can guarantee it's only called after
the GUC machinery has started up.

The elog code MUST be able to work before GUC initialization is done.
What do you think will happen if we fail to open postgresql.conf,
for example?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

How about dropping the brackets, and the cluster-name concept, and
just doing

postgres: 5432 checkpointer process

-1 for my part, as I'd just end up with a bunch of those and no
distinction between the various processes. In other words, without a
cluster distinction, it's useless.

Including the value of listen_addresses along w/ the port would make it
useful. If we really don't want the cluster-name concept (which,
personally, I like quite a bit), how about including the listen_address
value if it isn't '*'? I could see that also helping users who
installed from a distro and got '127.0.0.1' and don't understand why
they can't connect...

Of course, these are users who can use 'ps' but not 'netstat'. Not sure
how big that set really is.

Thanks,

Stephen

Stephen Frost <sfrost@snowman.net> writes:

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

How about dropping the brackets, and the cluster-name concept, and
just doing

postgres: 5432 checkpointer process

-1 for my part, as I'd just end up with a bunch of those and no
distinction between the various processes. In other words, without a
cluster distinction, it's useless.

Yeah, after I sent that I got to the bit about running multiple
postmasters with different IP-address bindings. I agree the port number
alone wouldn't be enough in that scenario.

Including the value of listen_addresses along w/ the port would make it
useful. If we really don't want the cluster-name concept (which,
personally, I like quite a bit), how about including the listen_address
value if it isn't '*'?

Nah, let's do cluster name. That way, somebody who's only got one
postmaster isn't suddenly going to see a lot of useless clutter,
ie the user gets to decide what to add to ps output. "SHOW cluster_name"
might be useful at the application level as well, I suspect.

I still think the brackets are unnecessary though.

Also, -1 for adding another log_line_prefix escape. If you're routing
multiple clusters logging to the same place (which is already a bit
unlikely IMO), you can put distinguishing strings in log_line_prefix
already. And it's not like we've got an infinite supply of letters
for those escapes.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

Including the value of listen_addresses along w/ the port would make it
useful. If we really don't want the cluster-name concept (which,
personally, I like quite a bit), how about including the listen_address
value if it isn't '*'?

Nah, let's do cluster name. That way, somebody who's only got one
postmaster isn't suddenly going to see a lot of useless clutter,
ie the user gets to decide what to add to ps output. "SHOW cluster_name"
might be useful at the application level as well, I suspect.

Ah, yes, agreed, that could be quite useful.

I still think the brackets are unnecessary though.

Either way is fine for me on this.

Also, -1 for adding another log_line_prefix escape. If you're routing
multiple clusters logging to the same place (which is already a bit
unlikely IMO), you can put distinguishing strings in log_line_prefix
already. And it's not like we've got an infinite supply of letters
for those escapes.

Agreed.

Thanks,

Stephen

On 2014-05-05 09:52:33 -0400, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

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.

That's true - but I am not sure you can guarantee it's only called after
the GUC machinery has started up.

The elog code MUST be able to work before GUC initialization is done.
What do you think will happen if we fail to open postgresql.conf,
for example?

But elog. shouldn't call init_ps_display(), right? Anyway, I am all for
initializing it sensibly, after all it was I that suggested doing so above...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-05-05 08:03:04 -0400, Stephen Frost wrote:

Craig,

* Craig Ringer (craig@2ndquadrant.com) wrote:

postgres[5433]: checkpointer process

at least as useful. The only time that's not unique is in a BSD jail or
lxc container, and in those cases IIRC ps can show you the
jail/container anyway.

Uhh, that's not at all true. You can trivially have multiple IPs on a
box w/o jails or containers (aliased interfaces) and then run PG on the
default port- which I find to be *far* more convenient than having the
same IP and a bunch of different ports.

Only that you then need different socket directories. Do you really do
that regularly?

Anyway, I am happy having the cluster_name thingy.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-05-05 10:07:46 -0400, Tom Lane wrote:

Stephen Frost <sfrost@snowman.net> writes:

Including the value of listen_addresses along w/ the port would make it
useful. If we really don't want the cluster-name concept (which,
personally, I like quite a bit), how about including the listen_address
value if it isn't '*'?

Nah, let's do cluster name. That way, somebody who's only got one
postmaster isn't suddenly going to see a lot of useless clutter,
ie the user gets to decide what to add to ps output. "SHOW cluster_name"
might be useful at the application level as well, I suspect.

Hm. What about unifiyng this with event_source? Not sure if it's a good
idea, but it's a pretty similar thing.

Also, -1 for adding another log_line_prefix escape. If you're routing
multiple clusters logging to the same place (which is already a bit
unlikely IMO), you can put distinguishing strings in log_line_prefix
already. And it's not like we've got an infinite supply of letters
for those escapes.

Using syslog and including the same config file from multiple clusters
isn't that uncommon. But I can live without it.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Andres Freund (andres@2ndquadrant.com) wrote:

On 2014-05-05 08:03:04 -0400, Stephen Frost wrote:

Uhh, that's not at all true. You can trivially have multiple IPs on a
box w/o jails or containers (aliased interfaces) and then run PG on the
default port- which I find to be *far* more convenient than having the
same IP and a bunch of different ports.

Only that you then need different socket directories. Do you really do
that regularly?

Yup. I've wished for that to be the default in Debian quite a few
times, actually... Much easier to deal with firewall rules and users
who are coming from pgAdmin and friends if they only have to deal with
understanding what hosts they need to connect to, and not worry about
the port also.

Anyway, I am happy having the cluster_name thingy.

Agreed.

Thanks,

Stpehen

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-05-05 10:07:46 -0400, Tom Lane wrote:

Also, -1 for adding another log_line_prefix escape. If you're routing
multiple clusters logging to the same place (which is already a bit
unlikely IMO), you can put distinguishing strings in log_line_prefix
already. And it's not like we've got an infinite supply of letters
for those escapes.

Using syslog and including the same config file from multiple clusters
isn't that uncommon. But I can live without it.

So, if you are sharing a config file, how is it that you can set a
per-cluster cluster_name but not a per-cluster log_line_prefix?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2014-05-05 13:07:48 -0400, Tom Lane wrote:

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-05-05 10:07:46 -0400, Tom Lane wrote:

Also, -1 for adding another log_line_prefix escape. If you're routing
multiple clusters logging to the same place (which is already a bit
unlikely IMO), you can put distinguishing strings in log_line_prefix
already. And it's not like we've got an infinite supply of letters
for those escapes.

Using syslog and including the same config file from multiple clusters
isn't that uncommon. But I can live without it.

So, if you are sharing a config file, how is it that you can set a
per-cluster cluster_name but not a per-cluster log_line_prefix?

Well, it's a included file. With log_line_prefix support just
cluster_name has to be set per cluster. Without you need string
interpolation in the config management to include cluster_name in
log_line_prefix.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers