From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Amit Langote <amitlangote09@gmail.com>,
 David Steele <david@pgmasters.net>,
        Pavel Biryukov <79166341370@yandex.ru>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: posgres 12 bug (partitioned table)
In-reply-to: <20210422183148.xsopy2qsym7a7app@alap3.anarazel.de>
References: <20200812162718.ycxrktzoe6rpdy5k@alap3.anarazel.de>
 <CA+HiwqEGgy8x5M2dotzH7HSd0v+byyJXGU8S+d5NFnrOBiTZDA@mail.gmail.com>
 <407111603806900@mail.yandex.ru>
 <CA+HiwqFjEim_RMCiaFxA4nUx00o3auXKPy-OsOcog+chg5K-zA@mail.gmail.com>
 <cd492dbd-a0ba-4790-bcf7-c4af2d2dc8d1@pgmasters.net>
 <CA+HiwqG7qhKJnFpZOqyrFngqcMzja+p=gssMK=73b+-BZffxqw@mail.gmail.com>
 <CA+HiwqHqnC=A9a+=F-k8J=JV-EKKt3vTgxq01=9af-0HE045NQ@mail.gmail.com>
 <793243.1619032209@sss.pgh.pa.us>
 <CA+HiwqGASb2n+fOKVgDUddzV-_vc6ZxRj9i5oWMWOw1VK0_c7g@mail.gmail.com>
 <1102101.1619115665@sss.pgh.pa.us>
 <20210422183148.xsopy2qsym7a7app@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Thu, 22 Apr 2021 11:31:48 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1130713.1619116646.1@sss.pgh.pa.us>
Date: Thu, 22 Apr 2021 14:37:26 -0400
Message-ID: <1130714.1619116646@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1130714.1619116646%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2021-04-22 14:21:05 -0400, Tom Lane wrote:
>> (1) It seems like this is exposing a shortcoming in the
>> multiple-slot-types logic.  It's not hard to understand why the slot would
>> look like this after execute_attr_map_slot does ExecStoreVirtualTuple,
>> but if this is not a legal state for a BufferHeapTuple slot, why didn't
>> ExecStoreVirtualTuple raise a complaint?

> I think it's too useful to support ExecStoreVirtualTuple() in a
> heap[buffer] slot to disallow that. Seems like we should make
> tts_buffer_heap_getsysattr() error out if there's no tuple?

OK, I could work with that.  Shall we spell the error message the
same as if it really were a virtual slot, or does it need to be
different to avoid confusion?

>> (2) It also seems like we can't use the srcSlot if we want to have
>> the fail-because-its-a-virtual-tuple behavior.  I experimented with
>> doing ExecMaterializeSlot on the result of execute_attr_map_slot,
>> and that stops the crash, but then we're returning garbage values
>> of xmin etc, which does not seem good.

> Garbage values as in 0's, or random data? Seems like it should be the
> former?

I was seeing something like xmin = 128.  I think this might be from
our filling in the header as though for a composite Datum.  In any
case, I think we need to either deliver the correct answer or throw
an error; silently returning zeroes wouldn't be good.

			regards, tom lane