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
