On Tues, Jan 10, 2023 at 0:00 AM Alex Richman <alexrichman@onesignal.com> wrote:
> I have also been poking around with gdb, looking at ReorderBufferGetTupleBuf
> and ReorderBufferChangeSize. There's certainly a difference in how they
> calculate the size, but they only differ by a handful of bytes so I don't
> understand where the 2 orders of magnitude difference between the Tuples
> memory context and rb->size is coming from.
>
> I am setting up a test environment to try and replicate this outside of prod. One
> oddity I can note already is that when I set up a logical replica chained off the
> current logical replica (primary -> LR 1 -> LR 2), the primary shows the memory
> spikes but the middle replica (LR 1) does not.
Hi, Alex
I think the commit c6e0fe1f2a in master may have an impact on this issue
because this commit reduce overheads of memory management. So I did some tests
(same test environment in [1]) and compared the results as below:
Before c6e0fe1f2a, for every additional 1MB configured in
logical_decoding_work_mem, the additional 141KB space will be allocated. While
in the current master, for every additional 1MB configured, the additional 47KB
space will be allocated.
In summary, with the commit c6e0fe1f2a in master, the additional space
allocated in the context is reduced. But I think this size difference seems to
be inconsistent with what you meet. So I think the issues you meet seems not to
be caused by the problem improved by this commit on master. How do you think?
If possible, could you please share which version of PG the issue occurs on,
and could you please also try to reproduce the problem on master?
Regards,
Wang Wei
[1] -
https://www.postgresql.org/message-id/OS3PR01MB6275677D0DAEC1132FD0AC7F9EFE9%40OS3PR01MB6275.jpnprd01.prod.outlook.com