Обсуждение: 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