> >> My bet is something depending on GetTickCount to measure elapsed > time > >> (and no, it's not used in the core Postgres code, but you've got > >> plenty of other possible culprits in that stack). > > > This doesn't quite make sense. The only reason we have to reboot > is > > because PostgreSQL no longer responds. The system itself is fine. > > The Windows kernel may still work, but that doesn't mean that > everything Postgres depends on still works. I'm wondering about > (a) the TCP stack (and that includes 3rd party firewalls and such, > not only the core Windows code); (b) timing or threading stuff > inside the application that's using libpq, which the only thing we > know about so far is that it's *not* JDBC/Hibernate.
How about getting a simple backtrace from a couple of the stuck postgres processes? And from the postmaster which should be accepting new connections... Or does that also hang completely? How to get one? Well, since we don't have the MSVC build yet (yeah, yeah, eventually), you can only get a semi-backtrace that only looks at exported symbols. You can get this using process explorer (thread tab, click stack), using WinDBG or using Visual Studio (you'll need VS 2005, and you need to check the option for "Load DLL exports" in options->debugging->native). Oh, btw, if there is a 3rd firewall on the box the standard recommendation of uninstalling it definitely sounds like a good plan :-) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
