Skip site navigation (1) Skip section navigation (2)

Re: \dS and \df <pattern> crashing psql

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Nishad PRAKASH <prakashn(at)uci(dot)edu>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: \dS and \df <pattern> crashing psql
Date: 2000-05-25 23:52:38
Message-ID: Pine.LNX.4.21.0005251236500.348-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Nishad PRAKASH writes:

> In psql, when connected to template1 as the postgres superuser, the
> \df function complains about some memory allocation problem.

The \d series of psql commands are really just shortcuts for various SQL
queries to the system catalogs. Start psql with the -E option to see them.
Therefore it is unlikely that this behaviour is entirely localized at
these functions. Have you run the regression tests without problems?

> can=# \dS
> The connection to the server was lost. Attempting reset: Failed.

Can you show the server output. There's probably a segmentation fault or
failed assertion in the backend involved, which we'd need to see.

> !# \d
> You are currently not connected to a database.
> !# \c can
> No Postgres username specified in startup packet.
> Segmentation fault

That's certainly a psql problem. Can you show a backtrace from gdb?


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e(at)gmx(dot)net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2000-05-26 00:04:05
Subject: Re: Any reason to use pg_dumpall on an idle database
Previous:From: Peter EisentrautDate: 2000-05-25 23:51:33
Subject: Re: AW: Performance (was: The New Slashdot Setup (includes MySqlserver))

pgsql-bugs by date

Next:From: Nishad PRAKASHDate: 2000-05-26 00:37:12
Subject: Re: \dS and \df <pattern> crashing psql
Previous:From: Travis BauerDate: 2000-05-25 19:04:28
Subject: Re: jdbc2 bug in absolute (ResultSet.java)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group