Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows - Mailing list pgsql-hackers

From David Rowley
Subject Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Date
Msg-id CAKJS1f-BC6kEDaigPLXrg4-JAXvTE8z4ooQj26vaQnqh+tA8pw@mail.gmail.com
Whole thread Raw
In response to Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
On 19 August 2015 at 12:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <david.rowley@2ndquadrant.com> writes:
> david=# set work_mem = '94GB';
> ERROR:  98566144 is outside the valid range for parameter "work_mem" (64 ..
> 2097151)

Apparently you're testing on a 32-bit server.  64-bit servers allow
work_mem to go up to INT_MAX kilobytes.

hmm, no, but it does appear that sizeof(long) is 4 bytes for me, despite 64 bit OS.

I guess this accounts for my misunderstanding that work_mem was limited to 2GB even on 64 bit machines.

From guc.h

#if SIZEOF_SIZE_T > 4 && SIZEOF_LONG > 4
#define MAX_KILOBYTES INT_MAX
#else
#define MAX_KILOBYTES (INT_MAX / 1024)
#endif 

Apologies for the noise.

pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: Our trial to TPC-DS but optimizer made unreasonable plan
Next
From: Michael Paquier
Date:
Subject: Re: allowing wal_level change at run time