Re: gppl-patch crash

Поиск
Список
Период
Сортировка
От David Helgason
Тема Re: gppl-patch crash
Дата
Msg-id F183076D-0B3E-11D9-ADEE-000A9566DA8A@uti.is
обсуждение исходный текст
Список 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
>


В списке pgsql-general по дате отправления:

Предыдущее
От: Mark Harrison
Дата:
Сообщение: using database for queuing operations?
Следующее
От: Jeff Amiel
Дата:
Сообщение: Re: using database for queuing operations?