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 letter
On Fri, Jul 4, 2014 at 10:33 AM, Tom Lane wrote:
> Vik Fearing 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 unfor
Vik Fearing 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 backward compatib
On 07/04/2014 08:50 AM, Fujii Masao wrote:
> On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing 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 it automatically
On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing 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 wrote:
> > So, I'd looked at it with an eye towards committing it and found some
> > more thi
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 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 clu
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 en
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 anybod
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 (pgsql-hackers@postg
On Sun, Jun 29, 2014 at 9:25 PM, Andres Freund wrote:
> On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
>> On 29 June 2014 10:55, Andres Freund 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 clus
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
> On 29 June 2014 10:55, Andres Freund 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 clu
On 29 June 2014 10:55, Andres Freund 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 shown
> in proces
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
> +
On 25 June 2014 08:13, Fujii Masao wrote:
> On Wed, Jun 25, 2014 at 1:29 PM, Abhijit Menon-Sen
> 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 got the following compiler warning.
On Thu, Jun 26, 2014 at 4:05 PM, Abhijit Menon-Sen 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. Yes, CONN_AUTH
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 ans
>> * 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 con
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 a/src/backend/uti
On 5 May 2014 17:22, Andres Freund wrote:
> On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
> > Andres Freund 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
On 2014-05-05 13:07:48 -0400, Tom Lane wrote:
> Andres Freund 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 p
Andres Freund 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.
* 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
On 2014-05-05 10:07:46 -0400, Tom Lane wrote:
> Stephen Frost 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
> > va
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 09:52:33 -0400, Tom Lane wrote:
> Andres Freund 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
> >> t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost 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
Stephen Frost 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 process
* 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
Andres Freund 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 everywhere if poss
On 5 May 2014 10:49, Thomas Munro wrote:
> On 5 May 2014 10:10, Andres Freund 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 wh
* 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
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 i
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 tr
* 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
On 2014-05-05 10:49:19 +, Thomas Munro wrote:
> On 5 May 2014 10:10, Andres Freund 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
> >
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
On 5 May 2014 10:10, Andres Freund 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 process" etc
>
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
38 matches
Mail list logo
