Обсуждение: Bug #829: 7.3 crashes when trying to set variable to default
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
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