Thread: Footer Text
I was just wondering why the list does not have any footer text at the bottom telling people how to unsubscribe, etc.. Who maintains the list?
Stephen Lawrence
webmaster@dairypower.com
webmaster@dairypower.com
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