Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Drouvot, Bertrand" <bdrouvot@amazon.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-09-07T05:58:24Z
Lists: pgsql-hackers
On Tue, Sep 7, 2021 at 11:10 AM Amit Kapila <amit.kapila16@gmail.com> wrote: >> Isn't it better if we use option 2) at all places as then we won't > >> need any special check inside ReorderBufferChangeMemoryUpdate()? > > > > > > If we want to do this then be careful about > REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID change. Basically, > ReorderBufferChangeMemoryUpdate() ignores this type of change whereas > ReorderBufferChangeSize(), consider at least sizeof(ReorderBufferChange) > bytes to this change. So if we compute the size using > ReorderBufferChangeSize() outside of ReorderBufferChangeMemoryUpdate(), > then total size will be different from what we have now. Logically, we > should be ignoring/asserting REORDER_BUFFER_CHANGE_INTERNAL_TUPLECID in > ReorderBufferChangeSize(), because ReorderBufferChangeMemoryUpdate() is the > only caller for this function. > > > > Why can't we simply ignore it in ReorderBufferChangeMemoryUpdate() as > we are doing now? > Yeah right, we can actually do that, it doesn't matter even if we are passing the size from outside. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Fix reorder buffer memory accounting for toast changes.
- 58cf794ca68d 13.5 landed
- f5e0ff4631b5 14.0 landed
- df3640e5293d 15.0 landed