Re: Invalid pointer access in logical decoding after error
От | Euler Taveira |
---|---|
Тема | Re: Invalid pointer access in logical decoding after error |
Дата | |
Msg-id | 8da2a299-e1a3-4d17-9758-8a183f47d321@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: Invalid pointer access in logical decoding after error (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Invalid pointer access in logical decoding after error
|
Список | pgsql-hackers |
On Mon, Oct 6, 2025, at 5:00 PM, Masahiko Sawada wrote: > I agree with your analysis. It seems there is no convenient way to > move RelationSyncCache inside PGOutputData. So let's proceed with the > proposed approach. > +1. Shouldn't we add a comment mentioning that it is a possibility? > I've done some minor changes to your v2 patch and updated the commit > message. IIUC this patch needs to be backpatched to v15. Please review > the attached patch. > I verified that the bug exists since v15 as reported. Despite of the test case provided by Vignesh (which I attached a modified version to be used in v15 or later), I also added another test case that has a similar problem with generated columns. This 2nd test case only works for v18 (where the feature was introduced). This patch also fixes this case. I'm curious about other cases related to RelationSyncCache. Is there any other cases that this patch doesn't fix? This patch looks good to me. Do we really need a new function with the same content as pgoutput_shutdown? I don't like mcallback. It seems 'm' stands for 'memory' but if we want to use crypt names I would suggest 'mcb' (_m_emory _c_all_b_ack) -- that is also a crypt name but a shorter one. Same pattern is already used in another place with MemoryContextCallback. -- Euler Taveira EDB https://www.enterprisedb.com/
Вложения
В списке pgsql-hackers по дате отправления: