| From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bgw_type (was Re: Why does logical replication launcher set application_name?) |
| Date: | 2017-09-25 16:31:32 |
| Message-ID: | 57c6f9ce-4fd3-6f4c-4ead-b2536b367772@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-09-25 16:35:19 | Re: logical replication and statistics |
| Previous Message | Petr Jelinek | 2017-09-25 16:30:16 | Re: logical replication and statistics |