Re: Invalid pointer access in logical decoding after error
От | vignesh C |
---|---|
Тема | Re: Invalid pointer access in logical decoding after error |
Дата | |
Msg-id | CALDaNm0JsF3UUmP0GToWOaBRRsCmrKS+2o865jEybqJVBD1E1g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Invalid pointer access in logical decoding after error (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Thu, 9 Oct 2025 at 23:33, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Oct 9, 2025 at 10:07 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Thu, Oct 9, 2025 at 8:23 AM Euler Taveira <euler@eulerto.com> wrote: > > > > > > On Thu, Oct 9, 2025, at 10:40 AM, vignesh C wrote: > > > > On Thu, 9 Oct 2025 at 00:16, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > >> > > > >> One thing we might want to consider is for v14 and v13. They don't > > > >> have this bug since the entry_ctx was introduced in v15, but it's > > > >> still true for them that RelationSyncCache is not cleaned up in error > > > >> cases if pgoutput is used via SQL API. For example, if > > > >> RelationSyncCache hash table gets corrupted for some reason, logical > > > >> decoding could repeat an error until logical decoding completes > > > >> successfully and its shutdown callback is called. Also, it might be a > > > >> good idea in general to ensure cleaning up the hash table after use. > > > > > > > > Agreed, let's backpatch to PG13. Should we also add a test case in the > > > > master branch, given that this issue has been around for a while? > > > > > > > > > > I'm wondering if it is a good idea because the bug doesn't manifest in v13 and > > > v14. At least the v13 has its final minor version in less than a month and EOL. > > > I would have caution when applying fixes to the latest minor version of a > > > stable branch; there won't be a chance to fix the fix in the next minor > > > release. Furthermore, in these back branches, the patch doesn't fix a known > > > issue. I wouldn't bother with these back branches. For v14, if, in a couple of > > > months, we have some reports that justify the backpatch, fine. > > > > Agreed. I'm hesitant with patching to v13 and v14. We've never got > > such a bug report yet and the next minior version of v13 would be the > > final release. I'll add some comments in the commit message. > > > > And now pushed (from master to v15). Thanks for committing the changes. I monitored the build farm, and the runs completed successfully. I've also closed the Cf entry at [1]. [1] - https://commitfest.postgresql.org/patch/5903/ Regards, Vignesh
В списке pgsql-hackers по дате отправления: