Seg fault in postgres 7.4.7?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Seg fault in postgres 7.4.7?

Akash Garg
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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Richard Huxton
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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Michael Fuhr
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/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Álvaro Herrera
In reply to this post by Akash Garg
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")

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Michael Fuhr
In reply to this post by Michael Fuhr
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/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Akash Garg
I looked in the data directory of postgres -- where else should I look for it?

Akash

On 7/6/05, Michael Fuhr <[hidden email]> 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/
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Reply | Threaded
Open this post in threaded view
|

Re: Seg fault in postgres 7.4.7?

Michael Fuhr
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/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly