Re: Decoding speculative insert with toast leaks memory
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>,
Petr Jelinek <petr.jelinek@enterprisedb.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2021-05-29T12:15:10Z
Lists: pgsql-hackers
On 5/29/21 6:29 AM, Amit Kapila wrote: > On Fri, May 28, 2021 at 5:16 PM Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> >> I wonder if there's a way to free the TOASTed data earlier, instead of >> waiting until the end of the transaction (as this patch does). >> > > IIUC we are anyway freeing the toasted data at the next > insert/update/delete. We can try to free at other change message types > like REORDER_BUFFER_CHANGE_MESSAGE but as you said that may make the > patch more complex, so it seems better to do the fix on the lines of > what is proposed in the patch. > +1 Even if we started doing what you mention (freeing the hash for other change types), we'd still need to do what the patch proposes because the speculative insert may be the last change in the transaction. For the other cases it works as a mitigation, so that we don't leak the memory forever. So let's get this committed, perhaps with a comment explaining that it might be possible to reset earlier if needed. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Fix ABI break introduced by commit 4daa140a2f.
- e95f617acc48 11.13 landed
- 72b51e214a2c 12.8 landed
- 56e366f6757d 13.4 landed
-
Fix valgrind issue in pgoutput.c.
- 357cb8f07f95 13.4 landed
-
Fix decoding of speculative aborts.
- 43acadfcebec 9.6.23 landed
- 35f56c124a7a 10.18 landed
- 1f8a934e0a86 11.13 landed
- 40ad7ebff6ca 12.8 landed
- 602a32a685e4 13.4 landed
- 4daa140a2f50 14.0 landed
-
pgoutput: Fix memory leak due to RelationSyncEntry.map.
- d2505681211b 13.4 cited
-
Fix initialization of RelationSyncEntry for streaming transactions.
- 69bd60672af6 14.0 cited
-
Implement streaming mode in ReorderBuffer.
- 7259736a6e5b 14.0 cited