Re: BUG #6222: Segmentation fault on unlogged table

On Mon, Sep 26, 2011 at 11:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> To check my work, I did this:
>
> --- a/src/backend/executor/execQual.c
> +++ b/src/backend/executor/execQual.c
> @@ -5003,6 +5003,7 @@ ExecQual(List *qual, ExprContext *econtext, bool
> resultForNull)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Datum =A0 =A0 =A0 =A0 =A0 expr_value;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bool =A0 =A0 =A0 =A0 =A0 =A0isNull;
>
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 Assert(!IsA(clause, List));
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0expr_value =3D ExecEvalExpr(clause, econte=
xt, &isNull, NULL);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (isNull)
>
> And in fact the test case (when run against the unlogged tables) fails
> that assertion:
>
> TRAP: FailedAssertion("!(!((((Node*)(clause))->type) =3D=3D T_List))",
> File: "execQual.c", Line: 5006)
>
> Now I'm not too sure why that is happening yet, but I'm leaning toward
> the idea that the bug here is timing-related and that unlogged tables
> aren't the cause, but rather just make it easier to hit whatever the
> race condition is by removing some overhead.

I cannot reproduce this on commit
e6faf910d75027bdce7cd0f2033db4e912592bcc.  But on the very next commit
I can:

commit e6faf910d75027bdce7cd0f2033db4e912592bcc
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Sep 16 00:42:53 2011 -0400

    Redesign the plancache mechanism for more flexibility and efficiency.

Tom, any thoughts?

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company