---------------------------------------------------------------------------
Slip number -----: 18
Problem ---------: DROP USER causes core dump if user created a database
Opened by -------: mascarim@yahoo.com on 07/26/99 00:17
Assigned To -----: momjian
---------------------------------------------------------------------------
Summary:
After creating a user 'mascari' using:
CREATE USER mascari CREATEDB;
as user 'postgres', a subsequent DROP USER
causes a Segmentation fault:
template1=> DROP USER mascari;
pqReadData() -- backend closed the channel
unexpectedly. This probably means the backend
terminated abnormally before or while processing
the request.
We have lost the connection to the backend, so
further processing is impossible. Terminating.
Here's the backtrace:
(gdb) bt
#0 0x8119e6c in AllocSetRealloc ()
#1 0x811a2f7 in pstrdup ()
#2 0x8119fe8 in MemoryContextRealloc ()
#3 0x8090b4b in RemoveUser ()
#4 0x80ec65d in ProcessUtility ()
#5 0x80e92e6 in pg_exec_query_dest ()
#6 0x80e91f4 in pg_parse_and_plan ()
#7 0x80ea448 in PostgresMain ()
#8 0x80d217c in PostmasterMain ()
#9 0x80d1cb3 in PostmasterMain ()
#10 0x80d1346 in PostmasterMain ()
#11 0x80d0eac in PostmasterMain ()
#12 0x80a4657 in main ()
This behavior only occurs if there exists a
database owned by the user being DROPPED. If
the database is DROPPED before the user is
DROPPED, everything works fine. So the repeatable
sequence to cause the core dump is:
As postgres in template1:
CREATE USER mascari CREATEDB;
As mascari in template1:
CREATE DATABASE test;
As postgres in template1:
DROP USER mascari;
Perhaps the DROP USER shouldn't be allowed when
databases exist under the to-be-dropped user's
domain? Or perhaps the behavior should mirror
that of DROP TABLE?
This is in the postgresql-6.5-1.rpm's from the
ftp site.
Mike Mascari
---------------------------------------------------------------------------
History:
07/26/99 12:47 by scrappy:
Dependency changed to 0 from
Current tech changed to momjian from
Status changed to O from U
Contact changed to from ANONYMOUS
Scheduled Close Date changed to 0 from
Scheduled Open Date changed to 0 from
Public setting changed to 1 from 0
Policy changed to 0
---------------------------------------------------------------------------
Full information on this slip is available at:
http://www.postgresql.org/bugs/visitor.php3?sid=18&v_func=zoom
---------------------------------------------------------------------------
This message was generated automatically by Keystone at http://www.postgresql.org
