If I do this as any user:

	SELECT update_pg_pwd();

it crashes all backends and causes a server-wide restart.  Is this
acceptable behavior?  I am sure there are other cases too.  Isn't it a
problem that we let ordinary users crash the server and cause a restart?

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

LOG:  server process (pid 23337) was terminated by signal 11
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing shared memory and semaphores
FATAL:  The database system is starting up
LOG:  database system was interrupted at 2002-03-21 03:42:08 CET
LOG:  checkpoint record is at 0/43C048
LOG:  redo record is at 0/43C048; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 99; next oid: 24747
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 0/43C088
LOG:  ReadRecord: record with zero length at 0/4421B4
LOG:  redo done at 0/442190
LOG:  database system is ready

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 20 Mar 2002 21:46:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Function call crashes server
Does the same thing here.

Sounds like a serious problem to me too.

Greg

On Wed, 2002-03-20 at 20:46, Bruce Momjian wrote:
> If I do this as any user:
> 
> 	SELECT update_pg_pwd();
> 
> it crashes all backends and causes a server-wide restart.  Is this
> acceptable behavior?  I am sure there are other cases too.  Isn't it a
> problem that we let ordinary users crash the server and cause a restart?
> 
> ---------------------------------------------------------------------------
> 
> LOG:  server process (pid 23337) was terminated by signal 11
> LOG:  terminating any other active server processes
> LOG:  all server processes terminated; reinitializing shared memory and semaphores
> FATAL:  The database system is starting up
> LOG:  database system was interrupted at 2002-03-21 03:42:08 CET
> LOG:  checkpoint record is at 0/43C048
> LOG:  redo record is at 0/43C048; undo record is at 0/0; shutdown TRUE
> LOG:  next transaction id: 99; next oid: 24747
> LOG:  database system was not properly shut down; automatic recovery in progress
> LOG:  redo starts at 0/43C088
> LOG:  ReadRecord: record with zero length at 0/4421B4
> LOG:  redo done at 0/442190
> LOG:  database system is ready
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
20 Mar 2002 22:37:33 -0600
Greg Copeland <greg@CopelandConsulting.Net>
Re: Function call crashes server
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If I do this as any user:
> 	SELECT update_pg_pwd();
> it crashes all backends and causes a server-wide restart.  Is this
> acceptable behavior?

There are a number of things we might blame this on, all having to do
with the overuse of type OID zero to mean too many different things.
But my attention is currently focused on this tidbit in ExecTypeFromTL:

            TupleDescInitEntry(typeInfo,
                               resdom->resno,
                               resdom->resname,
            /* fix for SELECT NULL ... */
                               (restype ? restype : UNKNOWNOID),
                               resdom->restypmod,
                               0,
                               false);

Had ExecTypeFromTL rejected restype = 0 rather than substituting
UNKNOWNOID (a pretty durn random response, IMHO), we'd not see this
crash.

The "fix for SELECT NULL" appears to have been committed by you
on 7 Dec 1996.  Care to explain it?

(AFAICT, "SELECT NULL" does not produce a zero at this point now,
though perhaps it did in 1996.  Or was there some other case you
were defending against back then?)

			regards, tom lane

Thu, 21 Mar 2002 00:08:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function call crashes server 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If I do this as any user:
> > 	SELECT update_pg_pwd();
> > it crashes all backends and causes a server-wide restart.  Is this
> > acceptable behavior?
> 
> There are a number of things we might blame this on, all having to do
> with the overuse of type OID zero to mean too many different things.
> But my attention is currently focused on this tidbit in ExecTypeFromTL:
> 
>             TupleDescInitEntry(typeInfo,
>                                resdom->resno,
>                                resdom->resname,
>             /* fix for SELECT NULL ... */
>                                (restype ? restype : UNKNOWNOID),
>                                resdom->restypmod,
>                                0,
>                                false);
> 
> Had ExecTypeFromTL rejected restype = 0 rather than substituting
> UNKNOWNOID (a pretty durn random response, IMHO), we'd not see this
> crash.
> 
> The "fix for SELECT NULL" appears to have been committed by you
> on 7 Dec 1996.  Care to explain it?
> 
> (AFAICT, "SELECT NULL" does not produce a zero at this point now,
> though perhaps it did in 1996.  Or was there some other case you
> were defending against back then?)

That was 6 months into the Internet-based project.  We were just
patching things to prevent crashes.  My guess is that I was trying to
fix the much more common case of "SELECT NULL" and had no idea how it
would affect functions that return no value.  Feel free to wack it
around.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 21 Mar 2002 00:13:33 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Function call crashes server
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Feel free to wack it around.

Removing the special-case logic in ExecTypeFromTL yields

regression=# SELECT update_pg_pwd();
ERROR:  getTypeOutputInfo: Cache lookup of type 0 failed

which is not exactly pretty, but it beats a core dump.  "SELECT NULL"
still works.

I'm satisfied with this until we get around to breaking up the uses of
"type OID 0" into several pseudo-types with crisper meanings, per
previous discussions.

			regards, tom lane

Thu, 21 Mar 2002 01:24:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Function call crashes server 
> regression=# SELECT update_pg_pwd();
> ERROR:  getTypeOutputInfo: Cache lookup of type 0 failed
>
> which is not exactly pretty, but it beats a core dump.  "SELECT NULL"
> still works.

Maybe the regression test database should have tests for all the built-in
functions?

Chris


Thu, 21 Mar 2002 14:39:21 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Function call crashes server 