Thread: jitflags in _outPlannedStmt and _readPlannedStmt treated as bool type

On Thu, Apr 26, 2018 at 9:04 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> The jitflags in the PlannedStmt structure of type "int", but in _out and
> _read functions it is treated as of "bool" type.
>
> WRITE_BOOL_FIELD(jitFlags);
> READ_BOOL_FIELD(jitFlags);
>
> I am thinking of it is a copy paste mistake as the other members around the
> initflags are of "bool" type or is there any specific reason to treat as
> "bool" type?

No, I don't see any. Here's patch for the same.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

On Thu, Apr 26, 2018 at 07:03:49PM +0530, Ashutosh Bapat wrote:
> On Thu, Apr 26, 2018 at 9:04 AM, Haribabu Kommi
>> I am thinking of it is a copy paste mistake as the other members around the
>> initflags are of "bool" type or is there any specific reason to treat as
>> "bool" type?
>
> No, I don't see any. Here's patch for the same.

The code is wrong, and you guys are right as well as the patch.  I have
added an open item to keep track of this one.
--
Michael

Hi,

On 2018-04-26 13:34:44 +1000, Haribabu Kommi wrote:
> The jitflags in the PlannedStmt structure of type "int", but in _out and
> _read functions it is treated as of "bool" type.
> 
> WRITE_BOOL_FIELD(jitFlags);
> READ_BOOL_FIELD(jitFlags);
> 
> I am thinking of it is a copy paste mistake as the other members around the
> initflags are of "bool" type or is there any specific reason to treat as
> "bool" type?

No, it's an oversight. It was a bool first and then morphed from
there... Will fix.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-04-26 13:34:44 +1000, Haribabu Kommi wrote:
>> I am thinking of it is a copy paste mistake as the other members around the
>> initflags are of "bool" type or is there any specific reason to treat as
>> "bool" type?

> No, it's an oversight. It was a bool first and then morphed from
> there... Will fix.

I went ahead and pushed this, as I'm intentionally thrashing the
buildfarm this afternoon in hopes of getting dory to show a reattach
failure.  (No luck so far :-()

            regards, tom lane

On April 28, 2018 1:47:56 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> On 2018-04-26 13:34:44 +1000, Haribabu Kommi wrote:
>>> I am thinking of it is a copy paste mistake as the other members
>around the
>>> initflags are of "bool" type or is there any specific reason to
>treat as
>>> "bool" type?
>
>> No, it's an oversight. It was a bool first and then morphed from
>> there... Will fix.
>
>I went ahead and pushed this, as I'm intentionally thrashing the
>buildfarm this afternoon in hopes of getting dory to show a reattach
>failure.  (No luck so far :-()

Thanks.

Perhaps Steven could change dory's config so it rebuilds when idle? There's a setting for that...

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Stephen Frost <sfrost@snowman.net> writes:
> On Sat, Apr 28, 2018 at 17:55 Andres Freund <andres@anarazel.de> wrote:
>> Perhaps Steven could change dory's config so it rebuilds when idle?
>> There's a setting for that...

> Not at a sufficiently capable keyboard at the moment to do that, so I’ve
> passed the ask on to someone else who can hopefully help. :)

Actually, I was about to ask whether you guys had changed anything about
dory's configuration recently.  It's now had eight consecutive passes
since I put in 63ca350 last night.  Given its record before that, just
about one failure in every three tries, the odds of that are less than 4%
if I'm counting on my fingers correctly.  So I'm wondering what changed;
and more change might not be what we want.

            regards, tom lane

Stephen Frost <sfrost@snowman.net> writes:
> On Sat, Apr 28, 2018 at 18:23 Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually, I was about to ask whether you guys had changed anything about
>> dory's configuration recently.  It's now had eight consecutive passes
>> since I put in 63ca350 last night.  Given its record before that, just
>> about one failure in every three tries, the odds of that are less than 4%
>> if I'm counting on my fingers correctly.  So I'm wondering what changed;
>> and more change might not be what we want.

> I’m not aware of any change today. I’ve asked when the last change was
> made.

If in fact nothing's been changed, then the run of successes is probably
just rotten luck.  (Either that or it's a Heisenbug, and the addition
of a VirtualQuery call made it go away.  Ugh.)  In that case I'm on board
with putting it into a continuous-rebuild loop till we get some failures.

            regards, tom lane