Thread: Re: pgsql: Fix unportable code in pgbench.

Re: pgsql: Fix unportable code in pgbench.

From
Fabien COELHO
Date:
Hello Tom,

> Fix unportable code in pgbench.

Sorry for this unforseen issue... portability is a pain:-(

> The buildfarm points out that UINT64_FORMAT might not work with sscanf;
> it's calibrated for our printf implementation, which might not agree
> with the platform-supplied sscanf.  Fall back to just accepting an
> unsigned long, which is already more than the documentation promises.

Yep, but ISTM that it is down to 32 bits, whereas the PRNG seed expects 48 
bits a few lines below:

     base_random_sequence.xseed[0] = iseed & 0xFFFF;
     base_random_sequence.xseed[1] = (iseed >> 16) & 0xFFFF;
     base_random_sequence.xseed[2] = (iseed >> 32) & 0xFFFF;

So the third short is now always 0. Hmmm. I'll propose another option over 
the week-end.

-- 
Fabien.



Re: pgsql: Fix unportable code in pgbench.

From
Tom Lane
Date:
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> Fix unportable code in pgbench.

> Sorry for this unforseen issue... portability is a pain:-(

I think it's my fault, actually --- I don't remember how much of
that patch was yours.

> Yep, but ISTM that it is down to 32 bits,

Only on 32-bit-long machines, which are a dwindling minority (except
for Windows, which I don't really care about).

> So the third short is now always 0. Hmmm. I'll propose another option over 
> the week-end.

I suppose we could put pg_strtouint64 somewhere where pgbench can use it,
but TBH I don't think it's worth the trouble.  The set of people using
the --random-seed=int option at all is darn near empty, I suspect,
and the documentation only says you can write an int there.

            regards, tom lane