On 8/31/17 23:22, Michael Paquier wrote: > On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> 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 >>> necessary to identity the process type. >> >> Updated patch incorporating the feedback. I have kept bgw_name as it >> was and just added bgw_type completely independently. > > - errmsg("terminating background worker \"%s\" due to > administrator command", > - MyBgworkerEntry->bgw_name))); > + errmsg("terminating %s due to administrator command", > + MyBgworkerEntry->bgw_type))); > "terminating background worker %s of type %s due to administrator > command", bgw_name, bgw_type?
OK. >> 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. The problem here is that we refer to bgw_type in a bunch of places now, and adding a suitable fallback in all of these places would be a lot of code and it would create a regression in behavior. In practice, I think that would be a lot of trouble for no gain. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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