don't allow walsender to consume superuser_reserved_connection slots, or during shutdown

On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ...shouldn't we move the "tests", plural, rather than just the one?
>> It seems right to reject new SR connections during shutdown.
>
> Yeah; you'd also need to adjust both of them to consider am_walsender.
> (IOW, we want to treat SR connections as non-superuser for both tests.)

[ subject changed, recipient list trimmed ]

Here's the fine patch. The actual code changes are simple and seem to
work as expected, but I struggled a bit with the phrasing of the
messages. Feel free to suggest improvements. Also, I wasn't sure if
there was somewhere in the documentation where we discussed the
restriction that only superusers can connect during shutdown. If
there is such a place, we should update that, too.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Here's the fine patch. The actual code changes are simple and seem to
> work as expected, but I struggled a bit with the phrasing of the
> messages. Feel free to suggest improvements.

Stick with the original wording? I don't really see a need to change it.

regards, tom lane

On Thu, Apr 22, 2010 at 11:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Here's the fine patch.  The actual code changes are simple and seem to
>> work as expected, but I struggled a bit with the phrasing of the
>> messages.  Feel free to suggest improvements.
>
> Stick with the original wording?  I don't really see a need to change it.

How about?:

if ((!am_superuser || am_walsender) &&
ReservedBackends > 0 &&
!HaveNFreeProcs(ReservedBackends))
{
if (am_walsender)
ereport(FATAL,
(errcode(ERRCODE_TOO_MANY_CONNECTIONS),
errmsg("remaining connection slots are reserved for
non-replication superuser connections")));
else
ereport(FATAL,
(errcode(ERRCODE_TOO_MANY_CONNECTIONS),
errmsg("connection limit exceeded for non-superusers")));
}

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Wed, Apr 21, 2010 at 10:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Here's the fine patch.  The actual code changes are simple and seem to
>> work as expected, but I struggled a bit with the phrasing of the
>> messages.  Feel free to suggest improvements.
>
> Stick with the original wording?  I don't really see a need to change it.

I don't think that's a good idea. If we just say that the remaining
connection slots are for superusers, someone will inevitably ask us
why their superuser replication can't connect. I think it's important
to phrase things as accurately as possible.

...Robert

On Wed, Apr 21, 2010 at 9:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Apr 21, 2010 at 1:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> ...shouldn't we move the "tests", plural, rather than just the one?
>>> It seems right to reject new SR connections during shutdown.
>>
>> Yeah; you'd also need to adjust both of them to consider am_walsender.
>> (IOW, we want to treat SR connections as non-superuser for both tests.)
>
> [ subject changed, recipient list trimmed ]
>
> Here's the fine patch.  The actual code changes are simple and seem to
> work as expected, but I struggled a bit with the phrasing of the
> messages.  Feel free to suggest improvements.  Also, I wasn't sure if
> there was somewhere in the documentation where we discussed the
> restriction that only superusers can connect during shutdown.  If
> there is such a place, we should update that, too.

I have committed this as-is. We can further change the error messages
if we like, but there didn't seem to be a clear consensus on any
particular change from what I have here.

...Robert