Re: Server process crash - Segmentation fault

Поиск
Список
Период
Сортировка
Искать
От
Leif Jensen
Тема
Re: Server process crash - Segmentation fault
Дата
в 13:59:24
Msg-id
7070852.11378.1399557549199.JavaMail.root@quick
Ответ на
Список
Дерево обсуждения
Re: Server process crash - Segmentation fault Leif Jensen <leif@crysberg.dk>
Re: Server process crash - Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process crash - Segmentation fault Leif Jensen <leif@crysberg.dk>
Re: Server process crash - Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process crash - Segmentation fault Leif Jensen <leif@crysberg.dk>
Re: Server process crash - Segmentation fault Adrian Klaver <adrian.klaver@aklaver.com>
Re: Server process crash - Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process crash - Segmentation fault Adrian Klaver <adrian.klaver@aklaver.com>
Re: Server process crash - Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: Server process crash - Segmentation fault Leif Jensen <leif@crysberg.dk>
Re: Server process crash - Segmentation fault Adrian Klaver <adrian.klaver@aklaver.com>
   Hi Tom,

   I already compiled postgreSQL myself and now using 9.3.4, so I would very much like a patch. Where can I find that ?

 Leif


----- Original Message -----
> Leif Jensen  writes:
> >    Could it be related to the OFFSET part of the statement ? I have
> >    another query on the same table without OFFSET, which seems to
> >    work fine.
> 
> Yeah, the specific code path here involves executing a stable (or
> possibly
> immutable) SQL function in a LIMIT or OFFSET clause. I was able to
> reproduce the crash like so:
> 
> create function foo(int) returns int as 'select $1 limit 1'
> language sql stable;
> 
> begin;
> 
> declare c cursor for select * from int8_tbl limit foo(3);
> 
> select * from c;
> 
> move backward all in c;
> 
> select * from c;
> 
> commit;
> 
> You might be able to dodge the problem if you can make the SQL
> function
> inline-able (the LIMIT 1 in my example is just to prevent that from
> happening). A less appealing alternative is to mark the function
> VOLATILE, which I think would also prevent this crash, but might have
> negative performance consequences.
> 
> If you don't mind building your own PG then you could grab the actual
> fix
> from our git repo; I should have something committed before long.
> 
> regards, tom lane

В списке pgsql-general по дате отправления
От: Adrian Klaver
Дата:
От: Tom Lane
Дата:
FAQ