Roberts, Jon wrote: >> 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. Yeah, that does seem like a reasonable explanation. Yet another reason not to use AV on your database server ;-) And if you absolutely have to, exclude the postgresql stuff. Since we do re-execute postgres.exe for every new connection, it's quite possible that the AV scanned it every single time, and it's a fairly large EXE... //Magnus
