From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Hadi Moshayedi <hadi@moshayedi.net>
Subject: Re: tableam scan-API patch broke foreign key validation
Date: Sat, 06 Apr 2019 14:43:26 -0400
Message-ID: <7309.1554576206@sss.pgh.pa.us> (raw)
In-Reply-To: <20190406183834.3dvhl24sxicgblaj@alap3.anarazel.de>
References: <19030.1554574075@sss.pgh.pa.us>
<FD203188-892D-4FD6-99F4-7E85027B60A7@anarazel.de>
<19246.1554574409@sss.pgh.pa.us>
<20190406182258.pvk5zkqdc6dobfg7@alap3.anarazel.de>
<19906.1554575674@sss.pgh.pa.us>
<20190406183834.3dvhl24sxicgblaj@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2019-04-06 14:34:34 -0400, Tom Lane wrote:
>> Why should this code need to free anything? That'd be the responsibility
>> of the slot code, no?
> Well, not really. If a slot doesn't hold heap tuples internally,
> ExecFetchSlotHeapTuple() will return a fresh heap tuple (but signal so
> by setting *should_free = true if not NULL).
Ah, got it: ignoring should_free is indeed a potential issue here.
>> But clearly we need a test case here. I'll adjust Hadi's example
>> so that there's more than one tuple to check, and push it.
> Cool.
Sounds like a plan.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, hadi@moshayedi.net
Subject: Re: tableam scan-API patch broke foreign key validation
In-Reply-To: <7309.1554576206@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox