> > If so, > > we could perhaps recode that part using a Mutex instead of > a critical > > section - since it's not a performance critical path, the > difference > > shouldn't be large. If I code up a patch for that, can you re-apply > > SP1 and test it? Or is this a production system you can't > really touch? > > I can do whatever the hell I want with it, so if you could > cook up a patch that would be great. > > As a BTW: I reinstalled SP1 and turned stats collection off. > That also seems to work, but is not really a solution since > we want to use autovacuuming.
Ok, I've coded up a patch that changes the code to use a mutex instead. Patch attached. You can get a precompiled postgres.exe at http://www.hagander.net/download/postgres.exe_mutex.zip. You need to copy this file to postmaster.exe as well - they are supposed to be identical. It's based off a snapshot of 8.1-stable. Looking a my system while testing this it still loooked like it was hanging on that plac ein the code, even though I saw no problems. So I'm not convinced we can actually trust the stacktrace from the non-default threads. So I don't think this patch will actually work :-( But it's worth a try. (Oh, and I moved the thread over to -hackers, seems more correct at this time) //Magnus
mutex.patch
Description: mutex.patch
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
