Re: [BUG] Failed Assertion in ReorderBufferChangeMemoryUpdate()
Drouvot, Bertrand <bdrouvot@amazon.com>
From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Dilip Kumar <dilipbalaut@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-09-07T06:03:38Z
Lists: pgsql-hackers
Hi, On 9/7/21 7:58 AM, Dilip Kumar wrote: > > On Tue, Sep 7, 2021 at 11:10 AM Amit Kapila <amit.kapila16@gmail.com > <mailto: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. Agree, if no objections, I'll prepare a patch with the modified approach of option 2) proposed by Amit (means passing the size from the outside in all the cases). Thanks Bertrand
Commits
-
Fix reorder buffer memory accounting for toast changes.
- 58cf794ca68d 13.5 landed
- f5e0ff4631b5 14.0 landed
- df3640e5293d 15.0 landed