Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
От | Duncan Sands |
---|---|
Тема | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Дата | |
Msg-id | 61ccd3cd-3185-4b07-9ce4-738c91546b54@deepbluecap.com обсуждение исходный текст |
Ответ на | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-bugs |
Dear Hayato Kuroda, I tried v4-PG17-0001-Avoid-distributing-invalidation-messages-sev.patch and I can confirm that it also resolves my original issue. Best wishes, Duncan. On 28/05/2025 14:27, Hayato Kuroda (Fujitsu) wrote: > Dear Sawada-san, Amit, > >>> It can impact the performance for large transactions with fewer >>> invalidations, especially the ones which has spilled changes because >>> it needs to traverse the entire list of changes again at the end. >> >> Agreed. >> >>> The >>> other idea would be to add new member(s) in ReorderBufferTXN to >>> receive distributed invalidations. For adding the new member in >>> ReorderBufferTXN: (a) in HEAD, it should be okay, (b) for >>> backbranches, we may be able to add at the end, but we should check if >>> there are any extensions using sizeof(ReorderBufferTxn) and if they >>> are using what we need to do. >> >> If we can make sure that that change won't break the existing >> extensions, I think this would be the most reasonable solution. > > Based on the discussion, I created PoC for master/PG17. Please see attached. > The basic idea is to introduce the new queue which only contains distributed inval > messages. Contents are consumed at end of transactions. I feel some of codes can > be re-used so that internal functions are introduced. At least, it could pass > regression tests and workloads discussed here. > > Best regards, > Hayato Kuroda > FUJITSU LIMITED >
В списке pgsql-bugs по дате отправления: