Re: Invalid pointer access in logical decoding after error
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-03T14:54:51Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix access-to-already-freed-memory issue in pgoutput.
- c40761759fe4 15.15 landed
- b07682bce301 16.11 landed
- a61592253e57 17.7 landed
- 32b95fc71b58 18.1 landed
- b46efe90482b 19 (unreleased) landed
-
Fix memory leak in pgoutput with publication list cache
- bbe68c13abe0 17.3 cited
Attachments
- v2-0001-Fix-referencing-invalid-pointer-in-logical-decodi.patch (text/x-patch) patch v2-0001
On Wed, 2 Jul 2025 at 13:21, Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > On Wed, Jul 2, 2025 at 2:42 PM vignesh C wrote: > > > > > Hi, > > > > I encountered an invalid pointer access issue. Below are the steps to > > reproduce the issue: > ... > > The error occurs because entry->columns is allocated in the entry > > private context (entry->entry_cxt) by pub_collist_to_bitmapset(). This > > context is a child of the PortalContext, which is cleared after an > > error via: AbortTransaction > > -> AtAbort_Portals -> > > MemoryContextDeleteChildren -> MemoryContextDelete -> > > MemoryContextDeleteOnly > > As a result, the memory backing entry->columns is freed, but the > > RelationSyncCache which resides in CacheMemoryContext and thus > > survives the error still holds a dangling pointer to this freed > > memory, causing it to pfree an invalid pointer. > > In the normal (positive) execution flow, pgoutput_shutdown() is called > > to clean up the RelationSyncCache. This happens via: > > FreeDecodingContext -> shutdown_cb_wrapper -> pgoutput_shutdown But > > this is not called in case of an error case. To handle this case > > safely, I suggest calling FreeDecodingContext in the PG_CATCH block to > > ensure pgoutput_shutdown is invoked and the stale cache is cleared appropriately. > > Attached patch has the changes for the same. > > Thoughts? > > Thank you for reporting the issue and providing a fix. > > I recall that we identified this general issue with the hash table in pgoutput > in other threads as well [1]. The basic consensus [2] is that calling > FreeDecodingContext() within PG_CATCH is not ideal, as this function includes > user code, increasing the risk of encountering another error within PG_CATCH. > This scenario could prevent execution of subsequent code to invalidate syscache > entries, which is problematic. Yes, let's avoid this. > I think a better fix could be to introduce a memory context reset callback(on > data->cachectx) and perform the actions of pgoutput_shutdown() within it. The attached v2 version patch has the changes for the same. Regards, Vignesh