Fix bogus use of "long" in aset.c

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Fix bogus use of "long" in aset.c
Date: 2025-10-29 23:07:08
Message-ID: CAApHDvo-RmiT4s33J=aC9C_-wPZjOXQ232V-EZFgKftSsNRi4w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
fix_AllocSetCheck_to_use_Size.patch application/octet-stream 597 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-29 23:12:26 Re: contrib/sepgsql regression tests have been broken for months
Previous Message Masahiko Sawada 2025-10-29 23:01:01 Re: Assertion failure in SnapBuildInitialSnapshot()