stack depth limit exceeded - patch possible?
Dear PostGre developers,
I'm working on Windows XP SP2 (stack limit set to 3500 kb) and deployed
successfully my Java application (doing some external Web service calling)
inside PostGre 8.3.0.
Unfortunatelly, the application needs at least 3 Threads and will run
for quite some time.
I found this comment
http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
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?
I'm not concerned about stability at all - just want to get
my things running for a proof-of-concept research prototype :)
My question is now if there is a patched version available of PostGre
8.3.0 having this stack_depth check disabled?
If so I would be very glad if you can point me to!
If not, can you tell me if
void check_stack_depth(void) in \src\backend\tcop\postgres.c
is the only place where to change something
(in my case just do nothing or report a warning)?
My C developer times are long gone but I would try to make a patched PostGre 8.3 version
myself.
Regards,
Alexander
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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
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:
Show quoted text
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.
Alexander Wöhrer <woehrer@par.univie.ac.at> writes:
Dear Gregory,
Thank you very much for you fast answer and your tips.
What is meant by IIUC?
"if I understand correctly"
Actually just one thread is accessing the database - the two others do
send/recieve data.
Then in theory it should work. But as I mention other people have run into a
number of problems with threads in the backend.
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.
I'm a bit confused why check_stack_depth matters if you're calling the
Postgres code from the original thread which called Java. If you're not in the
same thread as Postgres then you're still going to be in trouble.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
=?ISO-8859-1?Q?Alexander_W=F6hrer?= <woehrer@par.univie.ac.at> writes:
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.
It will crash ... but perhaps not until after it's hopelessly corrupted
your data. Don't try this on any database you care about.
regards, tom lane
On Sat, 12 Apr 2008, Alexander W�hrer wrote:
I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
successfully my application (doing some external Web service calling)
inside PostGre 8.3.0.Unfortunatelly, the application needs at least 3 Threads and will run
for quite some time.I found this comment
http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
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.My question is now if there is a patched version available of PostGre
8.3.0 having this stack_depth check disabled?
This was fixed in postgresql/pljava shortly after the referenced
discussion. As requested, postgresql 8.1+ allows modification of
stack_base_ptr so pljava can set it as desired.
Kris Jurka
Import Notes
Reply to msg id not found: 48010499.30000@par.univie.ac.atReference msg id not found: 48010499.30000@par.univie.ac.at | Resolved by subject fallback
Dear Kris,
am I understanding this correctly that pl/java sets it for the main Java
thread, so other threads spawned by this main thread and using postgres
SPI functionality will run into stack_depth_problems?
I have read only access in this application, so maybe my envisioned
patched version (check_stack_depth doing nothing) will work for my proof
of concept tests.
Can you suggest another workaround?
Regards,
Alexander W�hrer
Show quoted text
On Sat, 12 Apr 2008, Alexander W�hrer wrote:
I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
successfully my application (doing some external Web service calling)
inside PostGre 8.3.0.Unfortunatelly, the application needs at least 3 Threads and will run
for quite some time.I found this comment
http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
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.My question is now if there is a patched version available of PostGre
8.3.0 having this stack_depth check disabled?This was fixed in postgresql/pljava shortly after the referenced
discussion. As requested, postgresql 8.1+ allows modification of
stack_base_ptr so pljava can set it as desired.Kris Jurka
On Mon, 14 Apr 2008, Alexander Wöhrer wrote:
am I understanding this correctly that pl/java sets it for the main Java
thread, so other threads spawned by this main thread and using postgres
SPI functionality will run into stack_depth_problems?
pljava sets the stack_base_ptr for each thread just before it calls into
the backend using SPI and resets it when that thread finishes using SPI.
Only one thread can access the backend at a time, so multi-threaded pljava
code is safe and this mangling of the stack_base_ptr keeps the backend
happy.
Can you suggest another workaround?
Are you having any actual problems or is this all theoretical? I don't
believe you should be having any issues, but if you're having a real
problem, please post a self-contained test case so we can look into it.
Kris Jurka