Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Major breakage?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vadim Mikheev <vadim(at)krs(dot)ru>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Major breakage?
Date: 1999-01-26 19:43:44
Message-ID: 4656.917379824@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
>> Is anyone else seeing major breakage of the regression tests with
>> today's (Monday's) CVS checkins?  Or did I break something myself?

Nope, Vadim broke something.  It looks like anything with a subplan
will coredump in Monday's sources.  executor/nodeSubPlan.c has

bool
ExecInitSubPlan(SubPlan *node, EState *estate, Plan *parent)
{
    ...
    ExecCheckPerms(CMD_SELECT, 0, node->rtable, (Query *) NULL);
                                                ^^^^^^^^^^^^^^

(and has had that for a long time, evidently).  One of the additions
Vadim checked in yesterday extends ExecCheckPerms() to try to use
its parseTree argument --- unconditionally.  Guaranteed null-pointer
dereference.

Perhaps ExecInitSubPlan is in error to pass a null parseTree; if not,
then ExecCheckPerms needs to be modified to cope.  I don't understand
either routine enough to fix it correctly.

This bug is the cause of the opr_sanity coredump I'm seeing.
I don't have time to investigate the other test failures right now,
but very possibly they are the same thing.


BTW, anyone who is *not* seeing regression test coredumps with the
current CVS sources must have their compile/link options set so that
dereferencing a null pointer isn't fatal.  I think that's a very bad
choice for software development --- you want to hear about it, loud
and clear, if your code tries to use a null pointer.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1999-01-26 22:05:57
Subject: Re: [HACKERS] Major breakage?
Previous:From: Tom LaneDate: 1999-01-26 19:00:54
Subject: Re: [HACKERS] Re: alloca (was: Postgres Speed or lack thereof)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group