> 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