From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: =?utf-8?Q?Ond=C5=99ej?= Bouda <obouda@email.cz>,
        =?utf-8?Q?Ond=C5=99ej?= Bouda <bouda@edookit.com>,
        pgsql-general@lists.postgresql.org
Subject: Re: backend crash on DELETE, reproducible locally
In-reply-to: <20181106194553.dynhd2xuivo56ymd@alvherre.pgsql>
References: <20181106194553.dynhd2xuivo56ymd@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Tue, 06 Nov 2018 16:45:53 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <332.1541535248.1@sss.pgh.pa.us>
Date: Tue, 06 Nov 2018 15:14:08 -0500
Message-ID: <333.1541535248@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> What indexes are there in this table?  Indexes on expressions are
> particularly suspect.

I had not looked at the "projection index" code before, and now that
I have, I am desperately unhappy with it.  It's seriously buggy,
badly underdocumented, unbelievably inefficient, and it looks like
it creates a whole new set of reasons for unwanted recursion inside
the relcache.  The relcache has got NO business calling cost_qual_eval,
for example.

Having said that, I'm not real sure how it ends up with this crash.
It looks like ProjIndexIsUnchanged is getting the wrong value for
the index column's typbyval, but how could that be?

			regards, tom lane