problems with pg_dump... with postmaster really

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

I have found that the postmaster is dying very offen lattly, and yesterday I
got this error on a pg_dumpall:

connected to template1...
dumping database "horde"...
dumping database "lismarch"...
pg_dump: NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.

This does not look like pg_dump's fault --- its backend is getting
terminated because some *other* backend crashed, as the NOTICE is
apparently not making sufficiently clear.

What you need to find out is what that other backend was doing. Is
there a core dump file in any of your databases? Any entry in the
postmaster log about a failed child process? You will probably need
to provide a gdb stack trace from a core dump before we can help very
much. (It'd also be useful to know what PG version you are using.)

regards, tom lane

On Jue 23 May 2002 11:14, Tom Lane wrote:

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

I have found that the postmaster is dying very offen lattly, and
yesterday I got this error on a pg_dumpall:

connected to template1...
dumping database "horde"...
dumping database "lismarch"...
pg_dump: NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend
died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am
going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.

This does not look like pg_dump's fault --- its backend is getting
terminated because some *other* backend crashed, as the NOTICE is
apparently not making sufficiently clear.

What you need to find out is what that other backend was doing. Is
there a core dump file in any of your databases? Any entry in the
postmaster log about a failed child process? You will probably need
to provide a gdb stack trace from a core dump before we can help very
much. (It'd also be useful to know what PG version you are using.)

Could this be a php problem? The only client working on the DB server is php,
pg_dump, and ocationally psql when I work over the server. I could recompile
PHP.

P.D.: All this started after I upgraded PostgreSQL from 7.1.3 to 7.2.1.

--
Porqu� usar una base de datos relacional cualquiera,
si pod�s usar PostgreSQL?
-----------------------------------------------------------------
Mart�n Marqu�s | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

Could this be a php problem?

No. A backend crash is Postgres' fault, no matter what client software
you're using.

regards, tom lane

On Jue 23 May 2002 11:50, Tom Lane wrote:

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

Could this be a php problem?

No. A backend crash is Postgres' fault, no matter what client software
you're using.

But that php client was compiled with the PostgreSQL 7.1.3 libpg library, and
now I have a new one. That doesn't matter?

P.D.: The core files are only usefull for debugging????

--
Porqu� usar una base de datos relacional cualquiera,
si pod�s usar PostgreSQL?
-----------------------------------------------------------------
Mart�n Marqu�s | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

On Jue 23 May 2002 11:50, Tom Lane wrote:

No. A backend crash is Postgres' fault, no matter what client software
you're using.

But that php client was compiled with the PostgreSQL 7.1.3 libpg library, and
now I have a new one. That doesn't matter?

Not for this. If a backend crashes, that's a backend bug, no matter
*what* is talking to it.

regards, tom lane

On Jue 23 May 2002 11:58, Tom Lane wrote:

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

On Jue 23 May 2002 11:50, Tom Lane wrote:

No. A backend crash is Postgres' fault, no matter what client software
you're using.

But that php client was compiled with the PostgreSQL 7.1.3 libpg library,
and now I have a new one. That doesn't matter?

Not for this. If a backend crashes, that's a backend bug, no matter
*what* is talking to it.

OK. I thought it could have ben PHP because after installing I got a few
consecutive times this error until I restarted apache (with the mod_php) and
all went OK after.

At this moment I changed the ulimit to get the core files, ran pg_dumpall but
didn't get a problem with the backend.

What those this mean in the error:

pg_dump: query to obtain list of operators failed: server closed the
connection unexpectedly

--
Porqu� usar una base de datos relacional cualquiera,
si pod�s usar PostgreSQL?
-----------------------------------------------------------------
Mart�n Marqu�s | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

What those this mean in the error:
pg_dump: query to obtain list of operators failed: server closed the
connection unexpectedly

pg_dump is just telling you what it was doing when it lost the
connection. If I thought the problem had some connection to pg_dump
then I'd be more interested in that --- but I believe that the failure
is being triggered by one of your other client programs, not by pg_dump.

regards, tom lane