Re: Connection slots reserved for replication

On Thu, Feb 07, 2019 at 04:16:22PM +0100, Oleksii Kliukin wrote:
> On 7. Feb 2019, at 07:51, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I’ve noticed you returned the 'see max_connections’ parameter there. As noticed
> previously in this thread by Kyotaro Horiguchi, it’s not clear what exactly we
> are supposed to see there, perhaps it makes sense to elaborate (besides, the
> comment on max_wal_senders at guc.c:382 hints that max_wal_senders depends on
> max_connections, which is not true anymore).

After waking up on that, it seems that I overdid this part. I think
that I was trying to document the relationship with the multiple
parameters. Now it is true that it is easy enough to grep for the GUC
strings and find them. It may be better to avoid spawning the
calculations in the check functions in multiple lines as well.

>> It seems to me that it would be a good idea to have an
>> autovacuum-worker-related message in the context of InitProcess() for
>> a failed backend creation, but we can deal with that later if
>> necessary.
>
> Hm.. I am wondering how the autovacuum workers can run out of slots
> there?

Normally they cannot if you look at the way the launcher decides new
workers. Still, if one begins to hack the autovacuum code for a fork
or a new feature, I think that it would be useful to display a
context-related message instead of the confusing "too many clients" in
this case. This way it is possible to debug properly things.

>> With all that reviewed, I finish with the attached that I am
>> comfortable enough to commit. XLOG_PAGE_MAGIC is bumped as well, as a
>> reminder because xl_parameter_change gets an upgrade, and I am most
>> likely going to forget it.
>>
>> Please let me know if you have comments. I am still planning to do an
>> extra pass on it.
>
> Apart from the comment-related notes above your changes look good to
> me, thank you.

Thanks for the confirmation. I am not planning to finish wrapping
this one today anyway, and next week should be fine.
--
Michael