Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?) - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)
Date
Msg-id 57c6f9ce-4fd3-6f4c-4ead-b2536b367772@2ndquadrant.com
Whole thread Raw
In response to Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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 reporting an empty type string as NULL at SQL level and
>> just let it empty them? I tend to like more interfaces that report
>> exactly what is exactly registered at memory-level, because that's
>> easier to explain to users and in the documentation, as well as easier
>> to interpret and easier for module developers.
> 
> But then background workers that are not updated for, say, PG11 will not
> show anything useful in pg_stat_activity.  We should have some amount of
> backward compatibility here.
> 

Maybe the empty bgw_type could mean just "bgworker"?

--  Petr Jelinek                  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

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] logical replication and statistics
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] logical replication and statistics