Andres Freund writes:
> On 2020-11-08 12:46:44 -0500, Tom Lane wrote:
>> In v12 we end up using the junkfilter's output
>> slot, which does not have a sufficiently accurate tupdesc to deal with
>> an on-disk tuple rather than one constructed by the executor.
> I really wonder if we ought to redes
Hi,
On 2020-11-08 12:46:44 -0500, Tom Lane wrote:
> This logic is entirely gone in v12, which confirms my instinct that
> there was something about Andres' slot-manipulation changes that
> broke this scenario.
Entirely possible :(. In my defense, it wasn't exactly obvious or
documented that the f
I wrote:
> Yeah, this is sufficient reason why we must use the more invasive
> patch on those branches. What I'm wondering now is if there's a
> way to break even-older branches based on failure to handle dropped
> columns here.
After tracing through the example in v11, I see why those branches
a
"Drouvot, Bertrand" writes:
> Here is a scenario that produces segfault during update (on version 12
> and 13):
Hm. So the point about failing to reproduce dropped columns is more
critical than I thought. I wonder how come we get away with that before
v12?
> So, we would need to back port thi
