Re: shared memory corruption
От | Todd Nemanich |
---|---|
Тема | Re: shared memory corruption |
Дата | |
Msg-id | 3EC24AD9.40504@twopunks.org обсуждение исходный текст |
Ответ на | Re: shared memory corruption (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
This has happened once last month as well, but we were not able to nail it down then either. I'll restart the server when I get a chance to see if we can get a core dump next time it happens. THX. Tom Lane wrote: > Todd Nemanich <todd@twopunks.org> writes: > >> PostgreSQL version (example: PostgreSQL-7.3.1): PostgreSQL-7.3.1 >> Compiler used (example: gcc 2.95.2) : ? (PGDG 7.3.1 >>rpms on RH 7.3) > > >>May 13 14:01:17 db3 postgres[2618]: [1] LOG: server process (pid 14721) >>was terminated by signal 6 > > > Hmm. Signal 6 is SIGABORT, which suggests that that backend aborted > itself after detecting an Assert() failure. But I didn't think that > the RPM version was compiled with assertions enabled. Also, if it was > an assert then there should have been a complaint about it just before > the termination message. > > If this is repeatable, I'd suggest restarting the postmaster under > "ulimit -c unlimited" so that the abort will produce a core-dump file. > A debugger backtrace from the core file would provide useful info. > > regards, tom lane
В списке pgsql-bugs по дате отправления: