gppl-patch crash
(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
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:
Show quoted text
(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
Import Notes
Reply to msg id not found: EC77E683-0B23-11D9-ADEE-000A9566DA8A@uti.isReference msg id not found: EC77E683-0B23-11D9-ADEE-000A9566DA8A@uti.is | Resolved by subject fallback