Re: [HACKERS] Why does logical replication launcher setapplication_name?
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Why does logical replication launcher setapplication_name? |
Дата | |
Msg-id | 0d795703-a885-2193-2331-f00d7a3a4e42@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Why does logical replication launcher set application_name? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Why does logical replication launcher set application_name?
Re: [HACKERS] Why does logical replication launcher set application_name? |
Список | pgsql-hackers |
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 don't personally see why > we can't simply adopt Tom's original proposal of setting the query > string to something like "<logical replication launcher>" which, while > maybe not as elegant as providing some way to override the > backend_type field, would be almost no work and substantially better > for v10 than what we've got now. 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_activity field with some ad hoc information? What about other logical replication worker types, parallel workers, external background workers, auto-prewarm? I think the bgw_type addition that I proposed nearby would solve this quite well, but it needs a bit of work. And arguably, it's too late for PG10, but one could also argue that this is a design fault in the pg_stat_activity extension that is valid to fix in PG10. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: