Re: [COMMITTERS] pgsql: GIN index build's allocatedMemory counter needs to be long, not

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)postgresql(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: GIN index build's allocatedMemory counter needs to be long, not
Date: 2007-11-18 20:36:54
Message-ID: Pine.BSO.4.64.0711181231320.8039@resin.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Fri, 16 Nov 2007, Tom Lane wrote:

> GIN index build's allocatedMemory counter needs to be long, not uint32.
> Else, in a 64-bit machine with maintenance_work_mem set to above 4Gb,
> the counter overflows

I don't know if this has been discussed before, but you are aware that it
is not dictated by the C standard that sizeof(long) == sizeof(void*)?
The best counter-example I know is Windows x64, where sizeof(long) == 4
while sizeof(void*) == 8. The standards-compliant way to deal with this
IIRC is using size_t or ptrdiff_t, depending on whether or not you need it
to be signed.

Sorry if this has been discussed before, but this commit just struck me as
someone who has just been working at porting some software to Win64...

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2007-11-18 20:46:40 Re: Re: [COMMITTERS] pgsql: GIN index build's allocatedMemory counter needs to be long, not
Previous Message Tom Lane 2007-11-18 18:42:04 pgsql: Remove no-longer-accurate claim that REINDEX won't invalidate

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-11-18 20:46:40 Re: Re: [COMMITTERS] pgsql: GIN index build's allocatedMemory counter needs to be long, not
Previous Message Tom Lane 2007-11-18 19:51:02 Re: postgres dumps core - HASH indexes