Обсуждение: Seg fault in postgres 7.4.7?
My postgres 7.4.7 installation crashed on its own today -- here is the error log: ERROR: duplicate key violates unique constraint "toolbar_pkey" LOG: server process (PID 22753) was terminated by signal 11 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. Is this a known bug? Akash
Akash Garg wrote: > My postgres 7.4.7 installation crashed on its own today -- here is the > error log: > > ERROR: duplicate key violates unique constraint "toolbar_pkey" > LOG: server process (PID 22753) was terminated by signal 11 > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process > exited abnormally and possibly corrupted shared memory. > > Is this a known bug? Well - a sig-11 (segment violation/fault) is generally caused by dereferencing a pointer that is corrupted. So, it could be: 1. Hardware fault 2. Data corruption (of the index, caused by a previous crash) 3. Programming error. It's probably worth running one of the "memtest" tools to check you don't have a fault with your RAM chips. It could also be a fault in your disk controller/drives, but that's harder to test for (unless you're seeing disk errors). Before that though, make sure your backups are good (it doesn't hurt to be over-cautious). Re-index (see REINDEX command in manuals) the index in question, that can't hurt either if you've had a power-failure or similar in the past. OK - if you've ruled out memory problems and not had a crash then it might be a bug in 7.4.7. I've searched the "bugs" mailing list for the last 6 months at http://archives.postgresql.org/ Can't see anything there, so if it's a bug in the 7.4 series, you're the first to discover it. There might be something unusual about your installation. Can you give details (did you install from source/package, what OS, what OS version, character set, locale, any patches/add-on modules). -- Richard Huxton Archonet Ltd
On Wed, Jul 06, 2005 at 09:20:34AM +0100, Richard Huxton wrote: > > Can't see anything there, so if it's a bug in the 7.4 series, you're the > first to discover it. There might be something unusual about your > installation. Can you give details (did you install from source/package, > what OS, what OS version, character set, locale, any patches/add-on > modules). Did you get a core dump? If so then it might be useful to see a stack trace from it. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
On Tue, Jul 05, 2005 at 09:58:12PM -0700, Akash Garg wrote: > My postgres 7.4.7 installation crashed on its own today -- here is the > error log: > > ERROR: duplicate key violates unique constraint "toolbar_pkey" > LOG: server process (PID 22753) was terminated by signal 11 > LOG: terminating any other active server processes > WARNING: terminating connection because of crash of another server process > DETAIL: The postmaster has commanded this server process to roll back > the current transaction and exit, because another server process > exited abnormally and possibly corrupted shared memory. > > Is this a known bug? No. Do you have a core dump? Do you have any C functions, or triggers, or anything unusual? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) Officer Krupke, what are we to do? Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")
On Wed, Jul 06, 2005 at 06:55:09PM -0700, Akash Garg wrote: > This is Suse Enterprise 9.0 running on a quad Opteron Newisys machine. > It has 32 gb of RAM. We didn't do anything to fancy with the setup > of the OS or postgres. > > No core dump is available. Where did you look for a core dump? Do you have a resource limit or other setting that prevents them? -- Michael Fuhr http://www.fuhr.org/~mfuhr/
I looked in the data directory of postgres -- where else should I look for it? Akash On 7/6/05, Michael Fuhr <mike@fuhr.org> wrote: > On Wed, Jul 06, 2005 at 06:55:09PM -0700, Akash Garg wrote: > > This is Suse Enterprise 9.0 running on a quad Opteron Newisys machine. > > It has 32 gb of RAM. We didn't do anything to fancy with the setup > > of the OS or postgres. > > > > No core dump is available. > > Where did you look for a core dump? Do you have a resource limit > or other setting that prevents them? > > -- > Michael Fuhr > http://www.fuhr.org/~mfuhr/ >
On Mon, Jul 18, 2005 at 09:21:31AM -0700, Akash Garg wrote: > > I looked in the data directory of postgres -- where else should I look for it? Did you look everywhere beneath the data directory, or just in the data directory itself? Released versions of PostgreSQL typically dump core in $PGDATA/base/XXX, where XXX is the database OID. But on some systems you can configure where core dumps go and what name they have, so you might have to check your local settings. If you're sure you didn't get a core dump then you might have a resource limit like "coredumpsize" that prevents them from happening. If so, then it might be useful to adjust that limit so you can get core dumps. -- Michael Fuhr http://www.fuhr.org/~mfuhr/