Re: [HACKERS] Death on deletion attempts (was: Current sources?)

Tom Ivar Helbekkmo writes:
> t-ishii(at)sra(dot)co(dot)jp writes:
>
> > I have tested the s_lock_test and seems it is working. However I
> > have lots of failure with various SQL's including 'drop database',
> > 'delete from'.
>
> I'm seeing the same thing Tatsuo-san does. This is on NetBSD/sparc
> 1.3, GCC 1.7.2.2, running the very latest anonCVS-fetched PostgreSQL.
> Haven't run regression tests -- assume they would fail horribly. The
> installation was done from scratch, including an 'initdb' run.
>
> Interestingly, a 'delete from' will kill the backend even if it has a
> 'where' clause that does not match anything whatsoever, but a 'drop
> table' is fine, including non-empty tables. Brief testing of 'insert'
> and 'select' show them working, including joins, as do transactions
> using 'begin', 'commit' and 'abort'.
>
> Any idea where to start looking?

Not at me for starters ;-) I really think I _might_ be innocent here...

Btw, could you send me diffs for your bsd s_lock fix if you have not sent
them in to be applied yet. I would like avoid the multiple unsynched update
problem that happened last time. Thanks.

I did spend all of five minutes with gdb looking at the "drop database"
failure. It looks like ExecutorStart() returned a null tupleDesc to
ProcessQueryDesc() which then passed to BeginCommand() who did not like
it at all. So I would start looking at why ExecutorStart() failed.

The transcript is below:

Program received signal SIGSEGV, Segmentation fault.
BeginCommand (pname=0x0, operation=4, tupdesc=0x0, isIntoRel=0 '\000',
isIntoPortal=0, tag=0x81359c0 "DELETE", dest=Remote) at dest.c:241
241 AttributeTupleForm *attrs = tupdesc->attrs;
(gdb) where
#0 BeginCommand (pname=0x0, operation=4, tupdesc=0x0, isIntoRel=0 '\000',
isIntoPortal=0, tag=0x81359c0 "DELETE", dest=Remote) at dest.c:241
#1 0x80e24f9 in ProcessQueryDesc (queryDesc=0x81ba640) at pquery.c:293
#2 0x80e258e in ProcessQuery (parsetree=0x81b68f8, plan=0x81ba468, argv=0x0,
typev=0x0, nargs=0, dest=Remote) at pquery.c:378
#3 0x80e13b0 in pg_exec_query_dest (
query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0, dest=Remote) at postgres.c:702
#4 0x80e12b2 in pg_exec_query (
query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0) at postgres.c:601
#5 0x8096596 in destroydb (dbname=0x81b2558 "regression") at dbcommands.c:136
#6 0x80e304c in ProcessUtility (parsetree=0x81b2578, dest=Remote)
at utility.c:570
#7 0x80e1350 in pg_exec_query_dest (
query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0,
nargs=0, dest=Remote) at postgres.c:656
#8 0x80e12b2 in pg_exec_query (
query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0,
nargs=0) at postgres.c:601
#9 0x80e2001 in PostgresMain (argc=9, argv=0xbffff960) at postgres.c:1417
#10 0x80a7707 in main (argc=9, argv=0xbffff960) at main.c:105
(gdb) l
236 bool isIntoPortal,
237 char *tag,
238 CommandDest dest)
239 {
240 PortalEntry *entry;
241 AttributeTupleForm *attrs = tupdesc->attrs;
242 int natts = tupdesc->natts;
243 int i;
244 char *p;
245
(gdb) up
#1 0x80e24f9 in ProcessQueryDesc (queryDesc=0x81ba640) at pquery.c:293
293 BeginCommand(NULL,
(gdb) l 280,300
281 /* ----------------
282 * call ExecStart to prepare the plan for execution
283 * ----------------
284 */
285 attinfo = ExecutorStart(queryDesc, state);
286
287 /* ----------------
288 * report the query's result type information
289 * back to the front end or to whatever destination
290 * we're dealing with.
291 * ----------------
292 */
293 BeginCommand(NULL,
294 operation,
295 attinfo,
296 isRetrieveIntoRelation,
297 isRetrieveIntoPortal,
298 tag,
299 dest);
(gdb) p attinfo
$1 = (struct tupleDesc *) 0x0

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
and someone who knows less will correct me if I'm right."
--David Palmer (palmer(at)tybalt(dot)caltech(dot)edu)