| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgbench - minor fix for meta command only scripts |
| Date: | 2017-09-29 21:31:17 |
| Message-ID: | CA+Tgmoa41z4ptkD9P4e64=VV2pm6o1zNR-Wgz1qtLo5tcm+i5g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 11, 2017 at 4:49 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> Ok, the problem was a little bit more trivial than I thought.
>
> The issue is that under a low rate there may be no transaction in progress,
> however the wait procedure was relying on select's timeout. If nothing is
> active there is nothing to wait for, thus it was an active loop in this
> case...
>
> I've introduced a usleep call in place of select for this particular case.
> Hopefully this is portable.
>
> 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-09-29 21:40:12 | Re: Parallel Append implementation |
| Previous Message | Andres Freund | 2017-09-29 21:17:42 | Re: SendRowDescriptionMessage() is slow for queries with a lot of columns |