Re: gppl-patch crash

From: David Helgason <david(at)uti(dot)is>
To: Potemkin Evgen <gppl(at)inbox(dot)ru>
Cc: postgresql General <pgsql-general(at)postgresql(dot)org>
Subject: Re: gppl-patch crash
Date: 2004-09-20 19:54:55
Message-ID: F183076D-0B3E-11D9-ADEE-000A9566DA8A@uti.is
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ok, I was inspired by a dear colleague and went digging in the patch.

There's a #define named INIT_GUESS set to 1024 which looked very
tempting to change. It seems that that amount of tuples are reserved at
startup (or at some point anyway). Increasing it above my number of
clientstatus rows seems to make everything work.

Of course this is only a solution because I have a pretty (at least for
now) bounded number of rows in the clientstatus table.

Since the constant is called INIT_GUESS (initial guess), I'd assume
that it is supposed to resize if more data is received. This probably
doesn't get done.

I would be very thankful for a pointer to how to fix this (or a patch
even :)

Regards,

David Helgason,
Over the Edge (http://otee.dk) doing great game technology

On 20. sep 2004, at 18:41, David Helgason wrote:

> (I'm not quite sure which forum would be the right one, but since I'm
> pretty stuck I hope someone around here will have a suggestion)
>
> Using postgres 7.4.1 with version 0.5.3 of the gppl patch applied.
> Working like a charm under test conditions, but using a CONNECT BY
> statement with a large-ish start set (START WITH set of 1023 rows is
> sufficient, 1022 is not. Suspicious numbers I must say) the following
> crashes the backend with a signal 11:
>
>
> create table clientstate (asset integer);
> create table configuration (asset integer, parent integer);
>
> ... insert some 1290 rows into configuration, connecting asset-parent
> into a hierarchy (representing a directory tree, but doesn't seem to
> matter)
>
> begin work;
> insert into clientstatus (asset) select serial as asset from asset
> limit 1023;
> select count(*)
> from
> (select *
> from configuration
> connect by prior asset = parent start with asset in (select asset
> from clientstatus)) as s;
>
> rollback;
>
> I'm pretty blank here. Any leads? Not doing the select in a subselect
> removes the crash, so does having few enough objects in
> clientstatus... I tried browsing the code of the patch, but it's
> pretty opaque code and I didn't get any wiser.
>
>
> Regards,
>
> David Helgason,
> Over the Edge (http://otee.dk) doing great game technology
>

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Amiel 2004-09-20 20:08:29 Re: using database for queuing operations?
Previous Message Mark Harrison 2004-09-20 19:48:16 using database for queuing operations?