From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Hadi Moshayedi <hadi(at)moshayedi(dot)net> |
Subject: | Re: tableam scan-API patch broke foreign key validation |
Date: | 2019-04-08 05:54:40 |
Message-ID: | 20190408055440.x2xkdsnpg7qi4kxn@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-04-06 14:43:26 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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.
I've pushed a revised version of my earlier patch adding a memory
context that's reset after each tuple.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2019-04-08 06:01:46 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
Previous Message | Andres Freund | 2019-04-08 05:53:39 | Re: Shouldn't validateForeignKeyConstraint() reset memory context? |