Re: Fix memory counter update in reorderbuffer - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Fix memory counter update in reorderbuffer
Date
Msg-id CAA4eK1LzxrH-kObFyGu=KjgwJymcVFfg2sr5grq+mYkvWa6sQw@mail.gmail.com
Whole thread Raw
In response to Fix memory counter update in reorderbuffer  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Fix memory counter update in reorderbuffer
List pgsql-hackers
On Sat, Aug 3, 2024 at 1:21 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> I found a bug in the memory counter update in reorderbuffer. It was
> introduced by commit 5bec1d6bc5e, so pg17 and master are affected.
>
> In ReorderBufferCleanupTXN() we zero the transaction size and then
> free the transaction entry as follows:
>
>     /* Update the memory counter */
>     ReorderBufferChangeMemoryUpdate(rb, NULL, txn, false, txn->size);
>
>     /* deallocate */
>     ReorderBufferReturnTXN(rb, txn);
>

Why do we need to zero the transaction size explicitly? Shouldn't it
automatically become zero after freeing all the changes?

> However, if the transaction entry has toast changes we free them in
> ReorderBufferToastReset() called from ReorderBufferToastReset(),
>

Here, you mean ReorderBufferToastReset() called from
ReorderBufferReturnTXN(), right?

BTW, commit 5bec1d6bc5e also introduced
ReorderBufferChangeMemoryUpdate() in ReorderBufferTruncateTXN() which
is also worth considering while fixing the reported problem. It may
not have the same problem as you have reported but we can consider
whether setting txn size as zero explicitly is required or not.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Logical Replication of sequences
Next
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences