Re: [HACKERS] Why does logical replication launcher setapplication_name?
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Why does logical replication launcher setapplication_name? |
Дата | |
Msg-id | 35251f7d-dac2-35a4-18c6-cc7d09064ec7@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Why does logical replication launcher setapplication_name? (Petr Jelinek <petr.jelinek@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Why does logical replication launcher set application_name?
Re: [HACKERS] Why does logical replication launcher setapplication_name? |
Список | pgsql-hackers |
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? > But that does not solve the issue of identifying > the processes in pg_stat_activity as logical replication laucher/worker. > I wonder if it would be okay to set backend_type to bgw_name for > internal workers and just leave the external ones as it is (or solve > them in v11 with some proper API) as we can control the length of name > there (it will still be longer than the values for other things but > maybe not too much). I think showing bgw_name as backend_type always sounds reasonable. No need to treat external implementations differently. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: