Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
От | Masahiko Sawada |
---|---|
Тема | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Дата | |
Msg-id | CAD21AoDfbbF8RSvAgURXT=FycXkq1OBDJ5=-P+PccvYKQQf+3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Список | pgsql-bugs |
On Mon, Jun 2, 2025 at 4:35 AM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear Amit, Duncan, Vignesh, Sawada-san, > > I searched on GitHub and confirmed that no extensions use sizeof(ReorderBufferTXN). > Based on that, can we proceed with the fix for backbenches? > Note that I checked only repositories that are opened on GitHub. Proprietary > ones and hosting on other services cannot be guaranteed. > > How I search > =========== > I searched on github with "sizeof(ReorderBufferTXN)", and 259 files were found. > All of them were either "reorderbuffer.c" or "reorderbuffer.cpp". reorderbuffer.c > came from the forked postgres repos, and "reorderbuffer.cpp" came from the > openGauss project, which tries to enhance postgres. In both cases, they are > server-side code and will rebase community's commits when we update the header > file and sizeof(ReorderBufferTXN). > In this check, I could not find extensions that refer to the size; only > server-side codes were found. Based on that, we could extend the struct > ReorderBufferTXN. Thank you for checking the source codes on Github. I personally think the chance that extensions depend on the ReorderBufferTXN size is low. Without that, we would need more complex logic to store inval messages per-transaction, which introduce a risk. So I agree with the current solution. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-bugs по дате отправления: