Thread: Function call crashes server
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, Pennsylvania19026
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
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
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, Pennsylvania19026
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
> 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
> Removing the special-case logic in ExecTypeFromTL yields > > regression=# SELECT update_pg_pwd(); > ERROR: getTypeOutputInfo: Cache lookup of type 0 failed Wouldn't it be nice to make this a feature that allows stored procedures (void update_pg_pwd ()) ? Correctly register this function to not return anything ? This is what the 0 is actually supposed to mean here, no ? Such a proc would need a fmgr, that generates an empty resultset. Andreas
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> regression=# SELECT update_pg_pwd();
>> ERROR: getTypeOutputInfo: Cache lookup of type 0 failed
> Wouldn't it be nice to make this a feature that allows
> stored procedures (void update_pg_pwd ()) ? Correctly register
> this function to not return anything ? This is what the 0 is actually
> supposed to mean here, no ?
No, in this case the procedure is a trigger procedure and is not
supposed to be called directly at all. But we don't have a
distinguishable signature for triggers as yet. One of the changes
I'd like to make eventually is that trigger procs take and return
some special pseudo-type, so that the type system can catch this
sort of mistake explicitly.
regards, tom lane