Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
От | vignesh C |
---|---|
Тема | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Дата | |
Msg-id | CALDaNm0f=LgfQiV3oM3_4LOZrdLSSw8-+kUFvYNmxt4PYZymxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
|
Список | pgsql-bugs |
On Thu, 29 May 2025 at 22:57, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > I agree that chances are much lower than current if txn->invalidations > > doesn't contain invalidations from other transactions, but it is not > > clear what exactly you are trying to advocate by it. Are you trying to > > advocate that we should maintain a member similar to txn->invalidation > > (say txn->distributed_invals) instead of a queue? > > Yes, because I guess it's much simpler. I think it would not be a good > idea to introduce a new concept of accounting the memory usage of the > distributed inval messages too and serializing them, at least on back > branches. I think that In case where the txn->distriubted_inval is > about to overflow (not has to be 1GB) we can invalidate all caches > instread. To identify overflow scenarios, I’m considering the following options: a) Introduce a new txn_flags value, such as RBTXN_INVAL_ALL_CACHE, to explicitly mark transactions that require full cache invalidation. b) Add a dedicated parameter to indicate an overflow scenario. c) setting the newly added nentries_distr to -1, to indicate an overflow scenario. Do you have any preference or thoughts on which of these approaches would be cleaner? Regards, Vignesh
В списке pgsql-bugs по дате отправления: