Hello Robert,
>> ISTM that this bug exists since rate was introduced, so shame on me and
>> back-patching should be needed.
>
> I took a look at this and found that the proposed patch applies
> cleanly all the way back to 9.5, but the regression is reported to
> have begun with a commit that starts in v10. I haven't probed into
> this in any depth, but are we sure that
> 12788ae49e1933f463bc59a6efe46c4a01701b76 is in fact where this problem
> originated?
Yes.
I just rechecked that the problem occurs at 12788ae but not at the
preceding da6c4f6ca8.
Now the situation before the restructuring is that it worked but given the
spaghetti code it was very hard to guess why, not to fix issues when
not...
My late at night fuzzy interpretation is as follows:
The issue is in the code above the fix I submitted which checks what has
to be selected. In the previous version ISTM that the condition was laxed,
so it filled the input_mask even if the client was not waiting for
anything, so it was calling select later which was really just
implementing the timeout. With the updated version the input mask and
maxsock is only set if there is really something to wait, and if not then
it fall through and is active instead of doing a simple sleep/timeout.
So I would say that the previous version worked because of a side effect
which may or may not have been intentional at the time, and was revealed
by checking the condition better.
Basically I'd say that the restructuring patch fixed a defect which
triggered the bug. Programming is fun:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers