From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, Bo Thorbjørn Jensen <bo(at)budget123(dot)dk>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #7597: exception 0xC0000005 |
Date: | 2012-10-11 15:06:21 |
Message-ID: | 1134.1349967981@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> I see it too. I think the crash probably only occurs on a 32-bit build
> (or one where you've disabled int8-pass-by-value anyway). Looks like
> something's confused about cross-data-type comparisons --- this is an
> int4 vs int8 comparison, so it shouldn't be ending up at int8eq.
Argh ... the reason we're ending up at int8eq is that findPartialMatch
is using the wrong set of equality functions. hashtable->cur_eq_funcs
correctly references int8eq, but what we want to be using is the
SubPlanState's cur_eq_funcs. Amazing it took this long for anybody
to notice, because that's been wrong a long time.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit kapila | 2012-10-11 15:52:25 | Re: BUG #7534: walreceiver takes long time to detect n/w breakdown |
Previous Message | Heikki Linnakangas | 2012-10-11 14:52:40 | Re: BUG #7534: walreceiver takes long time to detect n/w breakdown |