Fix bogus use of "long" in aset.c - Mailing list pgsql-hackers

From David Rowley
Subject Fix bogus use of "long" in aset.c
Date
Msg-id CAApHDvo-RmiT4s33J=aC9C_-wPZjOXQ232V-EZFgKftSsNRi4w@mail.gmail.com
Whole thread Raw
Responses Re: Fix bogus use of "long" in aset.c
Re: Fix bogus use of "long" in aset.c
List pgsql-hackers
While reviewing another patch, I was playing around with a test case
to trigger a large memory allocation. I was doing this on Windows when
I got a nasty looking WARNING in a MEMORY_CONTEXT_CHECKING build:

create table t (a int);
insert into t values(1);
alter table t alter column a set (n_distinct = -1); -- all values distinct
analyze t;
update pg_class set reltuples = 1e9 where oid = 't'::regclass; -- hack
to make the table big
set work_mem = '4GB';
explain (summary on) select a from t except select a from t;

and got:
WARNING:  problem in alloc set ExecutorState: bad single-chunk
0000023DE7C98098 in block 0000023DE7C98070
WARNING:  problem in alloc set ExecutorState: bad single-chunk
0000023DE7C98098 in block 0000023DE7C98070

It turns out that AllocSetCheck() thinks "long" is a good datatype to
store the difference between 2 pointers. That's not going to work well
on 64-bit Windows as long is 32-bit.

I did also consider [u]intptr_t, but thought Size was better as that's
what chsize is.

Trivial fix attached.

David

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Assertion failure in SnapBuildInitialSnapshot()
Next
From: Tom Lane
Date:
Subject: Re: contrib/sepgsql regression tests have been broken for months