On Fri, Jul 4, 2014 at 10:33 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Vik Fearing vik.fear...@dalibo.com writes:
You mean that if synchronous_standby_names is an empty it automatically
should be set to cluster_name?
No, I mean that synchronous_standby_names should look at cluster_name
first,
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
On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing vik.fear...@dalibo.com wrote:
On 06/29/2014 02:25 PM, Andres Freund wrote:
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it
On 07/04/2014 08:50 AM, Fujii Masao wrote:
On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing vik.fear...@dalibo.com wrote:
Is there a reason for not using this in synchronous_standby_names,
perhaps falling back to application_name if not set?
You mean that if synchronous_standby_names is an empty
Vik Fearing vik.fear...@dalibo.com writes:
You mean that if synchronous_standby_names is an empty it automatically
should be set to cluster_name?
No, I mean that synchronous_standby_names should look at cluster_name
first, and if it's not set then unfortunately look at application_name
for
On 06/29/2014 02:25 PM, Andres Freund wrote:
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the
Abjit, all:
If we're adding log_line_prefix support for cluster_name (something I
think is a good idea), we need to also add it to CSVLOG. So, where do
we put it in CSVLog?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On 2014-06-30 12:10:53 -0700, Josh Berkus wrote:
Abjit, all:
If we're adding log_line_prefix support for cluster_name (something I
think is a good idea), we need to also add it to CSVLOG. So, where do
we put it in CSVLog?
That was shot down (unfortunately imo), and I don't think anybody
Hi,
On 2014-06-28 15:08:45 +0200, Andres Freund wrote:
Otherwise it looks good to me.
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the cluster name can only be ASCII. It's
shown from several clusters with differing
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the cluster name can only be ASCII. It's
shown from several clusters with differing encodings, and it's
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the cluster name can only be ASCII. It's
shown
On Sun, Jun 29, 2014 at 9:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
*
Hi,
On 2014-06-26 23:03:24 +0100, Thomas Munro wrote:
+ {cluster_name, PGC_POSTMASTER, CONN_AUTH_SETTINGS,
+ gettext_noop(Sets the name of the cluster that appears
in 'ps' output.),
+ NULL,
+ GUC_IS_NAME
+
At 2014-06-25 16:13:19 +0900, masao.fu...@gmail.com wrote:
Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me
Oh yes. Sorry, I meant to respond to this point in my original review,
but forgot. Yes, CONN_AUTH_SETTINGS is just weird. But I couldn't find
an obviously better
On Thu, Jun 26, 2014 at 4:05 PM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2014-06-25 16:13:19 +0900, masao.fu...@gmail.com wrote:
Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me
Oh yes. Sorry, I meant to respond to this point in my original review,
but forgot.
On 25 June 2014 08:13, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 25, 2014 at 1:29 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
The patch looks OK, and works as advertised (I tested on Linux). If we
want the feature (I like it), this patch is a good enough way to get it.
I
* cluster_name moved to config group CONN_AUTH_SETTINGS, on the
basis that it's similar to bonjour_name, but it isn't
really... open to suggestions for a better config_group!
Categorizing this parameter to CONN_AUTH_SETTINGS looks strange to me
because it's not directly related to
Hi.
I reviewed the version of this patch without log_line_prefix support,
since that seemed to be generally acceptable in followup discussion.
The patch didn't apply any more because of some changes to guc.c, but it
was trivial to regenerate (fixed patch attached).
diff --git
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
Hi,
On 2014-05-05 10:00:34 +, 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
On 5 May 2014 10:10, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-05-05 10:00:34 +, 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
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
On 2014-05-05 10:49:19 +, Thomas Munro wrote:
On 5 May 2014 10:10, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-05-05 10:00:34 +, Thomas Munro wrote:
When running more than one cluster I often find myself looking at
the output of 'iotop' or other tools wondering
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-05-05 10:00:34 +, 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.
Craig,
* Craig Ringer (cr...@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
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
* Andres Freund (and...@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
On 5 May 2014 10:49, Thomas Munro mu...@ip9.org wrote:
On 5 May 2014 10:10, Andres Freund and...@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.
Andres Freund and...@2ndquadrant.com writes:
On 2014-05-05 10:49:19 +, 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
* Tom Lane (t...@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
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@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
On 2014-05-05 09:52:33 -0400, Tom Lane wrote:
Andres Freund and...@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
On 2014-05-05 08:03:04 -0400, Stephen Frost wrote:
Craig,
* Craig Ringer (cr...@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
On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
Stephen Frost sfr...@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
* Andres Freund (and...@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
Andres Freund and...@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
On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
Andres Freund and...@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
On 5 May 2014 17:22, Andres Freund and...@2ndquadrant.com wrote:
On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
Andres Freund and...@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
39 matches
Mail list logo
