Re: pgsql: Refactor script execution state machine in pgbench. - Mailing list pgsql-committers

From Heikki Linnakangas
Subject Re: pgsql: Refactor script execution state machine in pgbench.
Date
Msg-id 57d482f5-f876-3377-c516-0d1e66cc78ee@iki.fi
Whole thread Raw
In response to Re: pgsql: Refactor script execution state machine in pgbench.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On 09/27/2016 02:25 AM, Tom Lane wrote:
> Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> Could you catch the process to identify the infinite loop?
>
> I think the problem is here (pgbench.c lines 4550ff):
>
>             bool        ready;
>             ...
>             ready = FD_ISSET(sock, &input_mask);
>
> The result of FD_ISSET isn't a bool, it's an int.  I can see in the
> looping process that the backend connection has socket FD 8, and
> I think what is happening is that FD_ISSET is returning 1<<8 and
> that's getting truncated to zero to fit in a bool (char), so that
> the code just below doesn't call doCustom and we never consume the
> waiting result.

Hah, good catch. It's quite a landmine that a macro named "is-something"
doesn't return a boolean. I remember we had issues like this in some
Postgres macros too, and added a "(<macro>) != 0)" into the macro
definition to fix. Of course, FD_ISSET is not in our control, and "bool"
is a Postgres thing anyway, so can't do that here.

> Will fix.

Thanks!

- Heikki



pgsql-committers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgsql: Refactor script execution state machine in pgbench.
Next
From: Fabien COELHO
Date:
Subject: Re: pgsql: Refactor script execution state machine in pgbench.