From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SPI TupTable memory context |
Date: | 2021-12-04 18:31:45 |
Message-ID: | 61ABB411.3060904@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/03/21 20:22, Tom Lane wrote:
> Seems kinda dangerous to me ...
>
>> AtEOSubXact_SPI can free tuptables retail, but only in the rollback case.
>
> ... precisely because of that. If you wanted to take control of
> the TupTable, you'd really need to unhook it from the SPI context's
> tuptables list, and that *really* seems like undue familiarity
> with the implementation.
Fair enough. I didn't have an immediate use in mind, but had been reading
through DestReceiver code and noticed it worked that way, and that it
looked as if an SPI_keeptuptable could have been implemented in probably
no more than the 25 lines of SPI_keepplan, and I wasn't sure if that was
because it had been considered and deemed a Bad Thing, or because the idea
hadn't come up.
The equivalent with a custom DestReceiver would certainly work, but with
a lot more ceremony.
So that was why I asked. If the response had been more like "hmm, no clear
reason a patch to do that would be bad", and if such a patch got accepted
for PG release n, that could also implicitly assuage worries about undue
familiarity for implementing the compatible behavior when building on < n.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-12-05 00:44:16 | Re: RecoveryInProgress() has critical side effects |
Previous Message | Chapman Flack | 2021-12-04 18:07:50 | Re: The "char" type versus non-ASCII characters |