Re: [HACKERS] pgbench - minor fix for meta command only scripts
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] pgbench - minor fix for meta command only scripts |
Дата | |
Msg-id | alpine.DEB.2.20.1709292356110.4754@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench - minor fix for meta command only scripts (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: