Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVzMb-0004cb-Us for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Oct 2020 15:52:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kVzMZ-0007Tr-LI for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Oct 2020 15:52:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVzMZ-0007Tj-FQ for pgsql-bugs@lists.postgresql.org; Fri, 23 Oct 2020 15:52:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVzMX-0007Z1-DO for pgsql-bugs@lists.postgresql.org; Fri, 23 Oct 2020 15:52:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09NFq904207143; Fri, 23 Oct 2020 11:52:09 -0400 From: Tom Lane To: Amit Langote cc: fedor_erastov@mail.ru, PostgreSQL mailing lists , Andres Freund , Andrew Dunstan Subject: Re: BUG #16644: null value for defaults in OLD variable for trigger In-reply-to: References: <16644-5da7ef98a7ac4545@postgresql.org> <802555.1601432494@sss.pgh.pa.us> Comments: In-reply-to Amit Langote message dated "Sat, 24 Oct 2020 00:36:56 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <207141.1603468329.1@sss.pgh.pa.us> Date: Fri, 23 Oct 2020 11:52:09 -0400 Message-ID: <207142.1603468329@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On Wed, Sep 30, 2020 at 11:21 AM Tom Lane 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