Re: Connection limits/permissions, slotsync workers, etc

"Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> writes:
> On Thursday, December 26, 2024 3:50 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> I wonder if the AV launcher and slotsync worker could be reclassified as "auxiliary
>> processes" instead of being their own weird animal.

> It appears that the current aux processes do not run transactions as stated in the
> comments[1], so we may need to somehow release this restriction to achieve the
> goal.

Ah, right, I'd forgotten about that restriction. I agree that
removing it wouldn't be very reasonable. However, I still would
rather avoid making the slotsync worker be its very own special
snowflake, because that offers no support for the next person
who wants to invent a new sort of specialized transaction-capable
process.

Attached is an alternative proposal that groups the autovac launcher
and slotsync worker into a new category of "special workers" (better
name welcome). I chose to put them into the existing autovacFreeProcs
freelist, partly because the autovac launcher lives there already
but mostly because I don't want to add another freelist in a patch
we need to put into v17. (As written, your patch is an ABI break.
It'd probably be safe to add a new freelist at the end of the struct
in v17, but I'm a little shy about that in view of recent bugs. In
any case, a freelist having at most two members seems rather silly.)

I was amused but not terribly surprised to notice that the comments
in InitProcGlobal were *already* out of date, in that they didn't
account for the walsender PGPROC pool. We have a remarkably bad
track record for updating comments that are more than about two
lines away from the code they describe :-(

Thoughts?

regards, tom lane