Re: BUG #5145: Complex query with lots of LEFT JOIN causes segfault

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

In response to

Browse pgsql-bugs by date

  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