Re: posgres 12 bug (partitioned table)

Hi,

On 2021-04-22 14:37:26 -0400, Tom Lane wrote:
> 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?

Hm. Seems like it'd be better to have a distinct error message? Feels
like it'll often indicate separate issues whether a non-materialized
heap slot or a virtual slot has its system columns accessed.


> >> (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.

I was wondering if we're not initializing memory somewhere were we
should...


> In any case, I think we need to either deliver the correct answer or
> throw an error; silently returning zeroes wouldn't be good.

IIRC there's some historical precedent in returning 0s in some
cases. But I don't think we should do that if we can avoid it.

Not entirely clear to me how we'd track whether we have valid system
column data or not once materialized - which I think is why we
historically had the cases where we returned bogus values.

Greetings,

Andres Freund