Re: [HACKERS] planner fails on HEAD

2011-12-05 Thread Merlin Moncure
On Sun, Dec 4, 2011 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was configured just with --enable-debug and --enable-cassert Is this x86?  I can't reproduce it on x86_64. reading

Re: [HACKERS] planner fails on HEAD

2011-12-05 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: On Sun, Dec 4, 2011 at 4:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was configured just with --enable-debug and --enable-cassert Is this x86?  

Re: [HACKERS] planner fails on HEAD

2011-12-05 Thread Merlin Moncure
On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello 2011/12/4 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was configured just with --enable-debug and --enable-cassert

Re: [HACKERS] planner fails on HEAD

2011-12-05 Thread Pavel Stehule
2011/12/5 Merlin Moncure mmonc...@gmail.com: On Mon, Dec 5, 2011 at 12:17 PM, Pavel Stehule pavel.steh...@gmail.com wrote: Hello 2011/12/4 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was

Re: [HACKERS] planner fails on HEAD

2011-12-05 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com writes: 2011/12/4 Tom Lane t...@sss.pgh.pa.us: Is this x86? I can't reproduce it on x86_64. yes, this is x86 platform uname -a Linux nemesis 2.6.35.14-106.fc14.i686.PAE #1 SMP Wed Nov 23 13:39:51 UTC 2011 i686 i686 i386 GNU/Linux I reproduced this

Re: [HACKERS] planner fails on HEAD

2011-12-04 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com writes: #3 0x083a1dfe in ExceptionalCondition (conditionName=0x8505474 !(innerstartsel = innerendsel), errorType=0x83db178 FailedAssertion, fileName=0x8505140 costsize.c, lineNumber=1937) at assert.c:57 [ scratches head ... ] Given that it got past the

Re: [HACKERS] planner fails on HEAD

2011-12-04 Thread Pavel Stehule
2011/12/4 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: #3  0x083a1dfe in ExceptionalCondition (conditionName=0x8505474 !(innerstartsel = innerendsel), errorType=0x83db178 FailedAssertion, fileName=0x8505140 costsize.c, lineNumber=1937) at assert.c:57 [

Re: [HACKERS] planner fails on HEAD

2011-12-04 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com writes: 2011/12/4 Tom Lane t...@sss.pgh.pa.us: [ scratches head ... ] Given that it got past the previous assertions, surely that ought to be impossible. Could we see the values of cost_mergejoin's local variables, please? It is strange when I put a

Re: [HACKERS] planner fails on HEAD

2011-12-04 Thread Pavel Stehule
2011/12/4 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: 2011/12/4 Tom Lane t...@sss.pgh.pa.us: [ scratches head ... ]  Given that it got past the previous assertions, surely that ought to be impossible.  Could we see the values of cost_mergejoin's local variables,

Re: [HACKERS] planner fails on HEAD

2011-12-04 Thread Tom Lane
Pavel Stehule pavel.steh...@gmail.com writes: it looks like gcc bug - gcc 4.5.1 20100924 (Red Hat 4.5.1) It was configured just with --enable-debug and --enable-cassert Is this x86? I can't reproduce it on x86_64. It's fairly easy to get a set of values such that innerstartsel *should* equal

[HACKERS] planner fails on HEAD

2011-12-03 Thread Pavel Stehule
Hello I have a relative simple query SELECT q.object_id FROM queue q JOIN outgoing.cps_forms f ON f.id = q.object_id AND q.object_type = 'cp' JOIN flat_file_ex fe ON fe.id = q.rejected_flat_file_id WHERE

Re: [HACKERS] planner fails on HEAD

2011-12-03 Thread Pavel Stehule
a plan for modified query is ohs=# explain analyze SELECT object_id, inserted, 'ASSIGN_RSLT', order_id, 2, seqnum, rejected_flat_file_id, true FROM ( SELECT q.object_id, fe.inserted, q.order_id, q.seqnum,