Footer Text

Server Pstgres 7.0.2-2
Server RedHat 6.1
Client RedHat 6.2

I'm developing a database schema that changes frequently. I have a
script that drops the database, then recreates it and creates tables and
functions. I've been running this sscript for some time, but lately,
psql on the clent machime aborts with this message:

psql:recreate-dbdom-db.pgsql:4: \connect: pqReadData() -- backend closed
the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
Segmentation fault (core dumped)

I get a core dump in the current directory on the client.
postmaster on the server machine keeps running as normal.

--
K. Ari Krupnikov

DBDOM - bridging XML and relational databases
http://www.iter.co.il

"K. Ari Krupnikov" <ari@iln.net> writes:

psql on the clent machime aborts with this message:

psql:recreate-dbdom-db.pgsql:4: \connect: pqReadData() -- backend closed
the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
Segmentation fault (core dumped)

I get a core dump in the current directory on the client.

No advice possible with so little information. What is the query
that triggers the crash? What are the definitions of the tables
used in the query? Can you get a backtrace from the psql coredump
(and also from the backend coredump, if there is one ... which seems
likely)?

regards, tom lane

Tom Lane wrote:

"K. Ari Krupnikov" <ari@iln.net> writes:

psql on the clent machime aborts with this message:

psql:recreate-dbdom-db.pgsql:4: \connect: pqReadData() -- backend closed
the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
Segmentation fault (core dumped)

I get a core dump in the current directory on the client.

No advice possible with so little information. What is the query
that triggers the crash? What are the definitions of the tables
used in the query? Can you get a backtrace from the psql coredump
(and also from the backend coredump, if there is one ... which seems
likely)?

this sequence causes the crash

# drop databse xxx;
# create database xxx;
# \c xxx;

and i was wrong when i said the backend doesn't crash - it does.

is there a limit on how many objects (tables, functions, etc) can be
created and dropped iin postgres?

--
K. Ari Krupnikov

DBDOM - bridging XML and relational databases
http://www.iter.co.il

"K. Ari Krupnikov" <ari@iln.net> writes:

I get a core dump in the current directory on the client.

this sequence causes the crash

# drop databse xxx;
# create database xxx;
# \c xxx;

and i was wrong when i said the backend doesn't crash - it does.

Can't reproduce this with current sources:

template1=# drop database xxx;
DROP DATABASE
template1=# create database xxx;
CREATE DATABASE
template1=# \c xxx;
FATAL 1: Database "xxx;" does not exist in the system catalog.
Previous connection kept
template1=# \c xxx
You are now connected to database xxx.
xxx=#

It's possible that 7.0.* psql has some since-repaired bug when trying
to \c to a nonexistent database name --- Peter, do you recall anything
like that?

regards, tom lane

Tom Lane writes:

It's possible that 7.0.* psql has some since-repaired bug when trying
to \c to a nonexistent database name --- Peter, do you recall anything
like that?

The psql sources haven't changed in that area, or much at all, since
7.0.2. Need to see a backtrace.

(I think we would have found obvious bugs in trying to connect to a
non-existent database pretty soon. I do that more than connecting to
existent databases. :)

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut wrote:

Tom Lane writes:

It's possible that 7.0.* psql has some since-repaired bug when trying
to \c to a nonexistent database name --- Peter, do you recall anything
like that?

(I think we would have found obvious bugs in trying to connect to a
non-existent database pretty soon. I do that more than connecting to
existent databases. :)

This happens when I connect to an *existing* (rather newly created)
database!
A script connects to template1; drops a database; creates it; connects
to it; the ther thing crashes.

--
K. Ari Krupnikov

DBDOM - bridging XML and relational databases
http://www.iter.co.il

"K. Ari Krupnikov" <ari@iln.net> writes:

This happens when I connect to an *existing* (rather newly created)
database!
A script connects to template1; drops a database; creates it; connects
to it; the ther thing crashes.

Not for us. You'll have to provide more info. Peter's request for
a stack traceback from the corefile seems like a good next step to me.
(Better compile with -g first, if you didn't already.)

regards, tom lane

Tom Lane wrote:

"K. Ari Krupnikov" <ari@iln.net> writes:

This happens when I connect to an *existing* (rather newly created)
database!
A script connects to template1; drops a database; creates it; connects
to it; the ther thing crashes.

Not for us. You'll have to provide more info. Peter's request for
a stack traceback from the corefile seems like a good next step to me.
(Better compile with -g first, if you didn't already.)

regards, tom lane

I reinstalled Postgres, and for now it seems fine: I can't recreate this
condition.
Maybe something got corrupted in my original instlation. Thanks for the
help.

--
K. Ari Krupnikov

DBDOM - bridging XML and relational databases
http://www.iter.co.il