pgsql: GIN index build's allocatedMemory counter needs to be long, not
Log Message:
-----------
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 and we never recognize having reached the
maintenance_work_mem limit. I believe this explains out-of-memory
failure recently reported by Sean Davis.
This is a bug, so backpatch to 8.2.
Modified Files:
--------------
pgsql/src/include/access:
gin.h (r1.14 -> r1.15)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gin.h?r1=1.14&r2=1.15)
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...
Jeremy Drake wrote:
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*)?
As evidenced by this piece of code in postgres.h:
typedef unsigned long Datum; /* XXX sizeof(long) >= sizeof(void *) */
The best counter-example I know is Windows x64, where sizeof(long) == 4
while sizeof(void*) == 8.
Yes, and there is lots of work left to do to support that.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
Jeremy Drake wrote:
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*)?
Yes, and there is lots of work left to do to support that.
Yeah. The current code convention is to use "long" when counting space
allocations --- see tuplesort.c for instance --- so I made this do
likewise. At some point we should try to migrate away from that,
but not today.
regards, tom lane