Re: pg crashing

Поиск
Список
Период
Сортировка
От Roberts, Jon
Тема Re: pg crashing
Дата
Msg-id 1A6E6D554222284AB25ABE3229A92762E9A689@nrtexcus702.int.asurion.com
обсуждение исходный текст
Ответ на Re: pg crashing  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: pg crashing  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-general
> Tom Lane wrote:
> > "Roberts, Jon" <Jon.Roberts@asurion.com> writes:
> >> Version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
> >
> > Well, there are plenty of known bugs in 8.3.0 by now.  You really
> > should update before complaining, not after.
>
> Yes. And the traditional question should be asked - is there any
> antivirus or other "personal security" software running on tihs
machine?
> If so, uninstall (not just disable!) it and see if the problem goes
away.

I am not able to un-install this.  However, this problem only started as
the database grew in size and usage.  It is 232 MB in size now and it
has 30 or so active sessions 24x7.

>
> >> 2008-07-01 10:46:30 CDT LOG:  all server processes terminated;
> >> reinitializing
> >
> > I think your real problem is with what happened *before* that.
>
> Agreed. There is some reason that they all terminated...
>

I just emailed a larger part of the log file.

>
> > But:
> >> 2008-07-01 10:46:31 CDT FATAL:  pre-existing shared memory block is
> >> still in use
> >> 2008-07-01 10:46:31 CDT HINT:  Check if there are any old server
> >> processes still running, and terminate them.
> >
> > Hmm ... the code in win32_shmem.c that generates this message seems
> > mighty bogus to me --- it's just hoping that one-second delay is
> > enough.
>
> Well, we're basically waiting for the kernel cleanup thread to get
run.
> In my tests it never came above 20ms or so, so 1 second is a pretty
long
> time.
>
> And you need *some* kind of timeout...
>
> It would also be interesting to know if there are actually any other
> processes running at this time.
>

Yes, there were about 30 active sessions executing functions.


> > Another problem is that postmaster children that do
> > PGSharedMemoryDetach will still have valid inherited handles for
> > the shmem segment --- does that factor into the behavior?  It looks
> > to me like the CloseHandle ought to be in PGSharedMemoryDetach.
>
> Not as long as the processes die. If they die, their handles go with
> them, and once the reference count goes to zero, the object goes away.
>
> //Magnus


В списке pgsql-general по дате отправления:

Предыдущее
От: "Roberts, Jon"
Дата:
Сообщение: Re: pg crashing
Следующее
От: "Roberts, Jon"
Дата:
Сообщение: Re: pg crashing