Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Duncan Sands <duncan.sands@deepbluecap.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2025-05-30T04:01:19Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix cache-dependent test failures in logical decoding.
- 87819f766f37 13.22 landed
-
Fix re-distributing previously distributed invalidation messages during logical decoding.
- d87d07b7ad3b 18.0 landed
- 45c357e0e85d 17.6 landed
- b2ae077205e1 16.10 landed
- fc0fb77c550f 15.14 landed
- 983b3636259b 14.19 landed
- 1230be12f086 13.22 landed
-
Fix data loss in logical replication.
- 247ee94150b6 13.21 cited
- 4909b38af034 18.0 cited