Bug #829: 7.3 crashes when trying to set variable to default

On Sun, 2002-12-01 at 16:35, pgsql-bugs@postgresql.org wrote:

alter user nobody set search_path to [something]

and then

alter user nobody set search_path to default

(having already done this for my own username).

The database server immediately crashes

Works for me:

template1=# select version();
version
----------------------------------------------------------------
PostgreSQL 7.3rc2 on i686-pc-linux-gnu, compiled by GCC 2.95.4
(1 row)

template1=# create user nobody;
CREATE USER
template1=# create schema a;
CREATE SCHEMA
template1=# alter user nobody set search_path to 'a';
ALTER USER
template1=# alter user nobody set search_path to default;
ALTER USER
template1=#

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

On Sun, 2002-12-01 at 17:03, Dustin Sallings wrote:

Around 16:54 on Dec 1, 2002, Neil Conway said:

# Works for me:

Well that's unfortunate, it crashes consistently for me.

Heh, ok. I thought my post implied "given the information you've given
me, I can't reproduce the bug, so can you give me some more info?" --
but perhaps I needed to be a little more explicit.

Can you get a backtrace from the core dump left by the backend when it
crashes? The core file should be located in
$PGDATA/base/$oid_of_current_db/ ; if you can recompile PostgreSQL with
debugging symbols (./configure --enable-debug) that should make it
easier to see what's going wrong.

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

I just tried:

test=> alter user postgres set search_path to 'public';
ALTER USER
test=> alter user postgres set search_path to default;
ALTER USER

and it worked fine here. This is with current CVS. Can anyone else
reproduce the problem?

---------------------------------------------------------------------------

pgsql-bugs@postgresql.org wrote:

Dustin Sallings (dustin+pgsqlbugs@spy.net) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
7.3 crashes when trying to set variable to default

Long Description
Logged in as dustin (superuser), I did the following:

alter user nobody set search_path to [something]

and then

alter user nobody set search_path to default

(having already done this for my own username).

The database server immediately crashes with the following message:

LOG: server process (pid 24975) was terminated by signal 10
[...]
LOG: all server processes terminated; reinitializing shared memory and semaphor
es
IpcMemoryCreate: shmget(key=5432001, size=2449408, 03600) failed: Cannot allocat
e memory

This error usually means that PostgreSQL's request for a shared
memory segment exceeded available memory or swap space.
To reduce the request size (currently 2449408 bytes), reduce
PostgreSQL's shared_buffers parameter (currently 128) and/or
its max_connections parameter (currently 64).

The PostgreSQL Administrator's Guide contains more information about
shared memory configuration.

My host system is OS X 10.2.2.

Sample Code

No file was uploaded with this report

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I just tried:
test=> alter user postgres set search_path to 'public';
ALTER USER
test=> alter user postgres set search_path to default;
ALTER USER
and it worked fine here. This is with current CVS. Can anyone else
reproduce the problem?

I can't reproduce it either (and I just finished trying it on OS X
10.2.2, so it's not just a matter of a platform dependency).

Dustin, we really need more info to proceed any further. How about
a stack backtrace?

regards, tom lane

Dustin Sallings <dustin@spy.net> writes:

Around 18:51 on Dec 1, 2002, Tom Lane said:
# I can't reproduce it either (and I just finished trying it on OS X
# 10.2.2, so it's not just a matter of a platform dependency).
#
# Dustin, we really need more info to proceed any further. How about a
# stack backtrace?

Well, I tried responding with what OS X gave me, but I'm not sure
if it made it through the list:

After fooling with it a little more, I see a problem that is not quite
what you said, but I bet it's what you meant:

regression=# create user foo;
CREATE USER
regression=# alter user foo set search_path to default;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

You can also get this by doing

regression=# alter user foo reset all;
ALTER USER
regression=# alter user foo set search_path to default;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

but as far as I can tell it will *not* happen once you've assigned any
user settings to the user (ie, once the user's useconfig field is not
null).

ALTER DATABASE has the identical bug.

Ah, teething pains :-(

regards, tom lane