From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
Date: Mon, 21 Aug 2023 12:30:22 -0400
Message-ID: <2863241.1692635422@sss.pgh.pa.us> (raw)
In-Reply-To: <7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net>
References: <20230821123337.fytudn7wtjlgtttk@alvherre.pgsql>
<7dc0e894-62ff-381c-b633-fa68250dd586@dunslane.net>
Andrew Dunstan <andrew@dunslane.net> writes:
> On 2023-08-21 Mo 08:33, Alvaro Herrera wrote:
>> Hmm ... when exactly do these values get freed if no longer needed? Is
>> the theory that leaking them is not relevant?
> Not sure I understand "relevant" here. They don't get freed. There will
> be at most one entry per row in pg_attribute where atthasmissing is
> true.
Yeah. My feeling is that as long as we don't make duplicate hashtable
entries, there will never be so many entries that it'd be worth the
cost and intellectual complexity of trying to clean them up. When
and if that theory is disproven, we can think harder; but for now
I think this approach is good enough.
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-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, alvherre@alvh.no-ip.org, andres@anarazel.de, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm()
In-Reply-To: <2863241.1692635422@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