On 2020-03-18 17:07, Mike Palmiotto wrote:
> On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto
> <mike.palmiotto@crunchydata.com> wrote:
>>
>> On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>>> Also, I saw this was failing tests both before and after my rebase.
>>>
>>> http://cfbot.cputube.org/
>>> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/builds/31535161
>>> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/builds/31386446
>>
>> Good catch, thanks. Will address this as well in the next round. Just
>> need to set up a Windows dev environment to see if I can
>> reproduce/fix.
>
> While I track this down, here is a rebased patchset, which drops
> MySubprocessType and makes use of the MyBackendType.
While working on (My)BackendType, I was attempting to get rid of
(My)AuxProcType altogether. This would mostly work except that it's
sort of wired into the pgstats subsystem (see NumBackendStatSlots).
This can probably be reorganized, but I didn't pursue it further.
Now, I'm a sucker for refactoring, but I feel this proposal is going
into a direction I don't understand. I'd prefer that we focus around
building out background workers as the preferred subprocess mechanism.
Building out a second generic mechanism, again, I don't understand the
direction. Are we hoping to add more of these processes? Make it
extensible? The net lines added/removed by this patch series seems
pretty neutral. What are we getting at the end of this?
More specifically, I don't agree with the wholesale renaming of
auxiliary process to subprocess. Besides the massive code churn, the
old naming seemed pretty good to distinguish them from background
workers, the new naming is more ambiguous.
Btw., if I had a lot of time I would attempt to rewrite walreceiver and
perhaps the autovacuum system as background workers and thus further
reduce the footprint of the aux process system.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services