From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | fedor_erastov(at)mail(dot)ru, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: BUG #16644: null value for defaults in OLD variable for trigger |
Date: | 2020-10-23 15:52:09 |
Message-ID: | 207142.1603468329@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Wed, Sep 30, 2020 at 11:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I've not tried to find where is the difference between 11 and
>> 12 that makes it fail or not fail.
> In v11, GetTupleForTrigger() expands the HeapTuple, with this:
> /*
> * While this is not necessary anymore after 297d627e, as a defense
> * against C code that has not recompiled for minor releases after the
> * fix, continue to expand the tuple.
> */
> if (HeapTupleHeaderGetNatts(tuple.t_data) < relation->rd_att->natts)
> result = heap_expand_tuple(&tuple, relation->rd_att);
> else
> result = heap_copytuple(&tuple);
> ReleaseBuffer(buffer);
Ah, good sleuthing.
>> I think we can band-aid this immediate problem by forcing
>> trigger.c to materialize the "old" tuples it fetches from disk
>> (or whatever needs to be done to substitute missing values into
>> them).
> Maybe something like the attached?
Probably needs some attention to memory management (e.g.,
should_free_trig) but I'm okay with doing this as a short-term
fix. I remain worried about similar instances elsewhere, but
I have no good ideas about how to find them.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Furs | 2020-10-23 16:36:59 | ADD TO UPDATE LIMIT |
Previous Message | Amit Langote | 2020-10-23 15:36:56 | Re: BUG #16644: null value for defaults in OLD variable for trigger |