From: kongsen.tian at tokuii.com (kstian) Date: Wed, 28 Sep 2005 14:38:27 +0800 Subject: [Pljava-dev] stack depth limit exceeded (NOT from infinite recursion) In-Reply-To: References: <4333C332.3060302@tokuii.com> <4333CDF5.9040207@mailblocks.com> <4333DB16.40904@tokuii.com> <4333DD5A.5030707@mailblocks.com> <4339F73C.8030106@tokuii.com> <433A2D41.2070009@mailblocks.com> Message-ID: <433A3A63.5020405@tokuii.com> Thanks a lot Thomas, "set the max_stack_depth to a ridiculously high value" appeared to work around the problem for now. This is the quickest solution at the moment and I will try that till I see another problem. Thanks again. Regards, Kong Thomas Hallgren wrote: > Kong, > PostgreSQL only defines one stack, and thus one stack_depth_limit. > It's not built for multiple threads and at present and PL/Java has no > way of telling PostgreSQL that another thread is about to do > something. PostgreSQL still thinks it's the same stack, hence the > problem. The stack-depth of the other thread is irrelevant. The > problem is caused by PostgreSQL comparing the stack_pointer from one > stack with the stack_base from another. > > You encounter this problem because a thread other then the main thread > is the first to encounter a class. That causes the classloader to make > an attempt to load the class in that thread. If you can find out what > class it is and then reference this class in advance from the main > thread, the problem will go away since the main thread will be the one > that loads the class. > > An alternative to this is to set the max_stack_depth to a ridiculously > high value and thus turn of stack checks altogether. I don't think > that will cause a major problem anyway. If you run into a > stack-overflow, the process will page-fault and terminate. > > I know none of those solutions are ideal but until I can convince the > PostgreSQL people to provide a function whereby I can set another > stack_base, there's nothing else I can do. > > Regards, > Thomas Hallgren > > kstian wrote: > >> Hi Thomas, >> >> Thanks a lot for the info. I went through reorganizing the installed >> jar file and reduced the size of the jar file to contain about 263 >> required class files (as compared to thousands originally). Then I >> re-ran the 3rd party connection from within pljava again and still >> seeing the same 'stack depth limit exceeded' problem. >> >> May I know what is the stack depth limit for the second thread that >> spawned from pljava? As of now, I have no idea how to work around >> this problem. >> >> Thanks so much. >> >> Regards, >> Kong >> >> Thomas Hallgren wrote: >> >>> OK, I see the problem. The connection spawns a new thread, that >>> thread loads classes. And of course, the stack of that thread cannot >>> be compared to the stack of the caller thread. PostgresSQL (since >>> it's singlethreaded) thinks that you eat a vast amount of stack. >>> >>> I'll address this on the PostgreSQL hackers mailing list and see if >>> I can convince them to install something that makes it possible to >>> temporary shut off the stack-check. A temporary work-around is to >>> reference the needed classes before making the connect call. That >>> way, the current thread will be the one who loads them. >>> >>> Regards, >>> Thomas Hallgren >> >> > > > >