Stefan Kaltenbrunner 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 nbatc
Stefan Kaltenbrunner writes:
> ok just assembled a new testcase from the querylog of the tool:
> http://www.kaltenbrunner.cc/files/rand_gen_crash.sql
Ah, that works (or should I say fails). Will take a look.
> However the error seems to go away after an ANALYZE... so I wonder if
> this is just
Greg Stark wrote:
On Fri, Oct 30, 2009 at 11:22 AM, Stefan Kaltenbrunner
wrote:
ok I now see why you (and I) failed to reproduce the problem - it only
causes clusters/databases to crash that were actually generated using the
upthread mentioned script. it does NOT fail using a dump generated by
On Fri, Oct 30, 2009 at 11:22 AM, Stefan Kaltenbrunner
wrote:
> ok I now see why you (and I) failed to reproduce the problem - it only
> causes clusters/databases to crash that were actually generated using the
> upthread mentioned script. it does NOT fail using a dump generated by a
> database th
Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Stefan Kaltenbrunner writes:
this is 8.5a2 configured with ./configure --enable-cassert
--enable-debug and just default settings(ie plain initdb with
default settings).
The OS is Debian Lenny/AMD64.
Huh. That should not be noticeably different
Tom Lane wrote:
Stefan Kaltenbrunner writes:
this is 8.5a2 configured with ./configure --enable-cassert
--enable-debug and just default settings(ie plain initdb with default
settings).
The OS is Debian Lenny/AMD64.
Huh. That should not be noticeably different from my F11/Xeon64
machine ..
Stefan Kaltenbrunner writes:
> this is 8.5a2 configured with ./configure --enable-cassert
> --enable-debug and just default settings(ie plain initdb with default
> settings).
> The OS is Debian Lenny/AMD64.
Huh. That should not be noticeably different from my F11/Xeon64
machine ... but I stil
Tom Lane wrote:
Stefan Kaltenbrunner writes:
uploaded a dump of the dataset here:
http://www.kaltenbrunner.cc/files/rand_gen_data.sql
and the query that causes the segfault:
http://www.kaltenbrunner.cc/files/rand_gen_query.sql
[ scratches head... ] Still no crash here, and I tried it on a co
Stefan Kaltenbrunner writes:
> uploaded a dump of the dataset here:
> http://www.kaltenbrunner.cc/files/rand_gen_data.sql
> and the query that causes the segfault:
> http://www.kaltenbrunner.cc/files/rand_gen_query.sql
[ scratches head... ] Still no crash here, and I tried it on a couple
differe
Tom Lane wrote:
Stefan Kaltenbrunner writes:
I can easily reproduce the segfault on 8.4 and 8.5a2:
Doesn't crash here ... could we see the specific test data being used,
please?
uploaded a dump of the dataset here:
http://www.kaltenbrunner.cc/files/rand_gen_data.sql
and the query that cau
On Thu, Oct 29, 2009 at 2:14 PM, Stefan Kaltenbrunner
wrote:
> ExecHashJoinSaveTuple (tuple=0xb49c8870, hashvalue=3316173823,
> fileptr=0x96185a8) at nodeHashjoin.c:775
> 775 BufFile *file = *fileptr;
>
That back trace doesn't make much sense. That function only has one
call site a
Stefan Kaltenbrunner writes:
> I can easily reproduce the segfault on 8.4 and 8.5a2:
Doesn't crash here ... could we see the specific test data being used,
please?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Bernt M. Johnsen wrote:
Euler Taveira de Oliveira wrote (2009-10-29 12:17:36):
Bernt Marius Johnsen escreveu:
The below query generated by the Random Query Generator
(https://launchpad.net/randgen) causes a segfault. It was caused running
Checkout the latest RQG from launchpad and run ./gent
Euler Taveira de Oliveira wrote (2009-10-29 12:17:36):
> Bernt Marius Johnsen escreveu:
> > The below query generated by the Random Query Generator
> > (https://launchpad.net/randgen) causes a segfault. It was caused running
> >
Checkout the latest RQG from launchpad and run ./gentes
Bernt Marius Johnsen escreveu:
> The below query generated by the Random Query Generator
> (https://launchpad.net/randgen) causes a segfault. It was caused running
>
Could you get a core dump and post the gdb backtrace?
$ ulimit -c unlimited
$ pg_ctl start
$ psql -c "" mydb
$ gdb /path/to/postgre
The following bug has been logged online:
Bug reference: 5145
Logged by: Bernt Marius Johnsen
Email address: bernt.john...@sun.com
PostgreSQL version: 8.3.8
Operating system: Linux 2.6.27-14 (Ubuntu Interpid)
Description:Complex query with lots of LEFT JOIN causes seg
16 matches
Mail list logo
