> Roberts, Jon wrote: > >> Not having looked at the internals of db_link, I'd say it's certainly > >> possible that this is the reason for the failed restart. If db_link is > >> blocking something, the postmaster can't kill it off, and it'll still > > be > >> sitting there holding a reference to the shared memory segment. > >> > >> That said, it shouldn't be the reason why it's crashing in the first > >> place - just the reason why it won't restart properly. > >> > > > > Is this a problem in Unix? We are about 1 - 2 weeks away from moving > > this database to Solaris. > > Not likely, but I'd test it anyway. If the issue is related to AV, it's > certainly fine - you won't be running AV on your Solaris. But more > importantly, Unix has actual support for signals and not just the fake > stuff we have on Win32, so it's likely that the postmaster will be > capable of killing the child processes. > Our AV program has been off for a while now and I haven't had a crash. I think part of the problem is how we have PostgreSQL installed and how eTrust is configured. We have the binaries installed on C:\program files\PostgreSQL\8.3\ and the data is located on E:\PostgreSQL\data\. We have eTrust excluding just E:\PostgreSQL\data\. I'm guessing the activity on the binaries causes some scanning which may have slowed down the cleanup enough to cause the crash to happen. Jon
