Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)

Поиск
Список
Период
Сортировка
От Petr Jelinek
Тема Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)
Дата
Msg-id 57c6f9ce-4fd3-6f4c-4ead-b2536b367772@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] logical replication and statistics
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] logical replication and statistics