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