On 9/27/17 18:59, Daniel Gustafsson wrote:
> The patch applies with minor fuzz, compiles without introduced warnings and
> work the way it says on the tin. The utility of the proposed functionality is
> a clear win so +1 on getting that in.
I have committed this patch incorporating the feedback i
On 8/31/17 23:22, Michael Paquier wrote:
> On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut
> wrote:
>> On 5/30/17 23:10, Peter Eisentraut wrote:
>>> Here is a proposed solution that splits bgw_name into bgw_type and
>>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>>> Uses
> On 31 Aug 2017, at 21:49, Peter Eisentraut
> wrote:
>
> On 5/30/17 23:10, Peter Eisentraut wrote:
>> Here is a proposed solution that splits bgw_name into bgw_type and
>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>> Uses of application_name are removed, because they
On 25/09/17 16:45, Peter Eisentraut wrote:
> On 8/31/17 23:22, Michael Paquier wrote:
>>> One open question is how to treat a missing (empty) bgw_type. I
>>> currently fill in bgw_name as a fallback. We could also treat it as an
>>> error or a warning as a transition measure.
>>
>> Hm. Why not re
On 8/31/17 23:22, Michael Paquier wrote:
>> One open question is how to treat a missing (empty) bgw_type. I
>> currently fill in bgw_name as a fallback. We could also treat it as an
>> error or a warning as a transition measure.
>
> Hm. Why not reporting an empty type string as NULL at SQL level
On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut
wrote:
> On 5/30/17 23:10, Peter Eisentraut wrote:
>> Here is a proposed solution that splits bgw_name into bgw_type and
>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>> Uses of application_name are removed, because they ar
On 5/30/17 23:10, Peter Eisentraut wrote:
> Here is a proposed solution that splits bgw_name into bgw_type and
> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
> Uses of application_name are removed, because they are no longer
> necessary to identity the process type.
Updated
On Tue, Jun 6, 2017 at 10:58 PM, Peter Eisentraut
wrote:
> The decision was made to add background workers to pg_stat_activity, but
> no facility was provided to tell the background workers apart. Is it
> now the job of every background worker to invent a hack to populate some
> other pg_stat_act
On Wed, Jun 7, 2017 at 4:58 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/6/17 15:58, Robert Haas wrote:
> > The problem with the status quo (after Peter's commit) is that there's
> > now nothing at all to identify the logical replication launcher, apart
> > from the wait_
On 6/6/17 15:58, Robert Haas wrote:
> The problem with the status quo (after Peter's commit) is that there's
> now nothing at all to identify the logical replication launcher, apart
> from the wait_event field, which is likely to be LogicalLauncherMain
> fairly often if you've got the launcher. I
On Sat, Jun 3, 2017 at 3:33 AM, Kuntal Ghosh wrote:
>> Agreed with this.
>>
>> However, I am not sure about the bgw_name_extra. I think I would have
>> preferred keeping full bgw_name field which would be used where full
>> name is needed and bgw_type where only the worker type is used. The
>> con
On 6/2/17 23:23, Peter Eisentraut wrote:
> On 6/2/17 15:08, Peter Eisentraut wrote:
>> On 5/30/17 23:10, Peter Eisentraut wrote:
>>> Here is a proposed solution that splits bgw_name into bgw_type and
>>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>>> Uses of application_na
On 03/06/17 05:18, Peter Eisentraut wrote:
> On 6/2/17 16:44, Petr Jelinek wrote:
>> However, I am not sure about the bgw_name_extra. I think I would have
>> preferred keeping full bgw_name field which would be used where full
>> name is needed and bgw_type where only the worker type is used. The
>
On Sat, Jun 3, 2017 at 4:33 PM, Kuntal Ghosh wrote:
> On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek
> wrote:
>> However, I am not sure about the bgw_name_extra. I think I would have
>> preferred keeping full bgw_name field which would be used where full
>> name is needed and bgw_type where only th
On Sat, Jun 3, 2017 at 8:53 AM, Peter Eisentraut
wrote:
> On 6/2/17 15:08, Peter Eisentraut wrote:
>> On 5/30/17 23:10, Peter Eisentraut wrote:
>>> Here is a proposed solution that splits bgw_name into bgw_type and
>>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>>> Uses o
On Sat, Jun 3, 2017 at 2:14 AM, Petr Jelinek
wrote:
> On 02/06/17 21:05, Peter Eisentraut wrote:
>> On 6/2/17 02:31, Masahiko Sawada wrote:
>>> I'd say current patch makes the user difficult to
>>> distinguish between apply worker and table sync worker.
>>
>> We could arguably make apply workers a
On 6/2/17 15:08, Peter Eisentraut wrote:
> On 5/30/17 23:10, Peter Eisentraut wrote:
>> Here is a proposed solution that splits bgw_name into bgw_type and
>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>> Uses of application_name are removed, because they are no longer
>> n
On 6/2/17 16:44, Petr Jelinek wrote:
> However, I am not sure about the bgw_name_extra. I think I would have
> preferred keeping full bgw_name field which would be used where full
> name is needed and bgw_type where only the worker type is used. The
> concatenation just doesn't sit well with me, es
On 02/06/17 21:05, Peter Eisentraut wrote:
> On 6/2/17 02:31, Masahiko Sawada wrote:
>> I'd say current patch makes the user difficult to
>> distinguish between apply worker and table sync worker.
>
> We could arguably make apply workers and sync workers have different
> bgw_type values. But if y
On 5/30/17 23:10, Peter Eisentraut wrote:
> Here is a proposed solution that splits bgw_name into bgw_type and
> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
> Uses of application_name are removed, because they are no longer
> necessary to identity the process type.
>
> Thi
On 6/2/17 02:31, Masahiko Sawada wrote:
> On Wed, May 31, 2017 at 12:10 PM, Peter Eisentraut
> wrote:
>> Here is a proposed solution that splits bgw_name into bgw_type and
>> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
>> Uses of application_name are removed, because they
On Wed, May 31, 2017 at 12:10 PM, Peter Eisentraut
wrote:
> Here is a proposed solution that splits bgw_name into bgw_type and
> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
> Uses of application_name are removed, because they are no longer
> necessary to identity the proce
Here is a proposed solution that splits bgw_name into bgw_type and
bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type.
Uses of application_name are removed, because they are no longer
necessary to identity the process type.
This code appears to be buggy because I sometimes get NUL
On Tue, May 23, 2017 at 07:50:34PM +0200, Petr Jelinek wrote:
> On 20/04/17 21:33, Peter Eisentraut wrote:
> > On 4/18/17 13:18, Tom Lane wrote:
> >> I think you're thinking about it wrong. To my mind the issue is that
> >> there should be some generic way to determine that a bgworker process
> >>
On 20/04/17 21:33, Peter Eisentraut wrote:
> On 4/18/17 13:18, Tom Lane wrote:
>> I think you're thinking about it wrong. To my mind the issue is that
>> there should be some generic way to determine that a bgworker process
>> is or is not laboring on behalf of an identifiable user. It's great
>>
On 4/18/17 13:18, Tom Lane wrote:
> I think you're thinking about it wrong. To my mind the issue is that
> there should be some generic way to determine that a bgworker process
> is or is not laboring on behalf of an identifiable user. It's great
> that we can tell which user it is when there is
On 4/18/17 12:37, Tom Lane wrote:
> Peter Eisentraut writes:
>> I think showing bgw_name as backend_type always sounds reasonable. No
>> need to treat external implementations differently.
>
> That's definitely an approach we could use. It would encourage people
> to use short bgw_names, which
On 18/04/17 19:18, Tom Lane wrote:
> Petr Jelinek writes:
>> On 18/04/17 18:24, Peter Eisentraut wrote:
>>> I don't see why we need to do that. It is showing the correct
>>> information, isn't it?
>
>> It does, but it's also one of the things Tom complained about and I
>> think he is right in th
Petr Jelinek writes:
> On 18/04/17 18:24, Peter Eisentraut wrote:
>> I don't see why we need to do that. It is showing the correct
>> information, isn't it?
> It does, but it's also one of the things Tom complained about and I
> think he is right in that at least values for launcher should be
>
On 18/04/17 18:24, Peter Eisentraut wrote:
> On 4/18/17 12:13, Petr Jelinek wrote:
>> We can definitely easily detect that the bgworker is internal one by
>> library_name equals 'postgres' so we can easily remove the usesysid and
>> usename based on that.
>
> I don't see why we need to do that. I
Peter Eisentraut writes:
> I think showing bgw_name as backend_type always sounds reasonable. No
> need to treat external implementations differently.
That's definitely an approach we could use. It would encourage people
to use short bgw_names, which is a constraint that wasn't especially
appar
On 4/18/17 12:13, Petr Jelinek wrote:
> We can definitely easily detect that the bgworker is internal one by
> library_name equals 'postgres' so we can easily remove the usesysid and
> usename based on that.
I don't see why we need to do that. It is showing the correct
information, isn't it?
> B
On 16/04/17 22:27, Petr Jelinek wrote:
> On 16/04/17 18:47, Tom Lane wrote:
>> Craig Ringer writes:
>>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
For backend_type=background worker, application_name shows the name of
the background worker (BackgroundWorker->bgw_name). I think we ne
On 16/04/17 18:47, Tom Lane wrote:
> Craig Ringer writes:
>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
>>> For backend_type=background worker, application_name shows the name of
>>> the background worker (BackgroundWorker->bgw_name). I think we need
>>> some way to distinguish among differen
Craig Ringer writes:
> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
>> For backend_type=background worker, application_name shows the name of
>> the background worker (BackgroundWorker->bgw_name). I think we need
>> some way to distinguish among different background workers. But,
>> application
On 12/04/17 02:32, Robert Haas wrote:
> On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier
> wrote:
>> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote:
>>> I notice looking at pg_stat_activity that the logical replication launcher
>>> sets its application_name to "logical replication launcher". Th
On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
> For backend_type=background worker, application_name shows the name of
> the background worker (BackgroundWorker->bgw_name). I think we need
> some way to distinguish among different background workers. But,
> application_name may not be the correc
On Wed, Apr 12, 2017 at 6:02 AM, Robert Haas wrote:
> On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier
> wrote:
>> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote:
>>> I notice looking at pg_stat_activity that the logical replication launcher
>>> sets its application_name to "logical replication
On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier
wrote:
> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote:
>> I notice looking at pg_stat_activity that the logical replication launcher
>> sets its application_name to "logical replication launcher". This seems
>> inconsistent (no other standard b
On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote:
> I notice looking at pg_stat_activity that the logical replication launcher
> sets its application_name to "logical replication launcher". This seems
> inconsistent (no other standard background process sets application_name),
> redundant with oth
I notice looking at pg_stat_activity that the logical replication launcher
sets its application_name to "logical replication launcher". This seems
inconsistent (no other standard background process sets application_name),
redundant with other columns that already tell you what it is, and an
unreas
41 matches
Mail list logo