Re: stack depth limit exceeded - patch possible?
От | Alexander Wöhrer |
---|---|
Тема | Re: stack depth limit exceeded - patch possible? |
Дата | |
Msg-id | 48011D54.2060104@par.univie.ac.at обсуждение исходный текст |
Ответ на | Re: stack depth limit exceeded - patch possible? (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: stack depth limit exceeded - patch possible?
Re: stack depth limit exceeded - patch possible? |
Список | pgsql-hackers |
Dear Gregory, Thank you very much for you fast answer and your tips. What is meant by IIUC? Actually just one thread is accessing the database - the two others do send/recieve data. I will try my luck anyway and try to built PostGre 8.3 without check_stack_depth doing anything - will let you know what happens for my application. Best regards, Alexander Gregory Stark schrieb: > Alexander Wöhrer <woehrer@par.univie.ac.at> writes: > > >> by Thomas Hallgren where he mentioned that PostGre only defines >> one stack and therefor pl/java has no way of telling PostGre >> about multiple thread stack pointers. >> >> As far as I understand the situation, the check_stack_depth() >> is used "just" to provide better stability/security? >> > > That's only going to be the tip of the iceberg. None of the Postgres internal > functions are thread-safe, they don't lock any internal data structures except > those shared with other backends. > > If you're going to use Postgres internal API functions then you only have any > hope of doing so from a single thread. And even then people have run into some > problems. > > You might look into PL/J which IIUC runs the java stack in a second process > rather than in the server process. Or you could run PL/Java but have it > communicate with your application over a socket, you could send whole > serialized objects over. > >
В списке pgsql-hackers по дате отправления: