From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, "Bernt M(dot) Johnsen" <Bernt(dot)Johnsen(at)sun(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5145: Complex query with lots of LEFT JOIN causes segfault |
Date: | 2009-10-30 19:03:50 |
Message-ID: | 14790.1256929430@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> However the error seems to go away after an ANALYZE... so I wonder if
> this is just another case of "if we missestimated the size of the
> hashtable we are doomed"
Actually, what seems to be happening on a 32-bit machine is that
ExecChooseHashTableSize sets nbatch = INT_MAX/2, and then when we
try to do
hashtable->outerBatchFile = (BufFile **)
palloc0(nbatch * sizeof(BufFile *));
the memory size calculation overflows to zero, so we get an empty
outerBatchFile array. So the fix is to make sure we limit the
number of batches to something sane, perhaps work_mem / sizeof(pointer).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-10-30 19:09:13 | Re: BUG #5151: autovacuum process segfaults when max_fsm_pages are too low |
Previous Message | Tom Lane | 2009-10-30 18:52:35 | Re: BUG #5145: Complex query with lots of LEFT JOIN causes segfault |