Re: Odd code around ginScanToDelete
Pavel Borisov <pashkin.elfe@gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2026-03-10T09:28:53Z
Lists: pgsql-hackers
Hi, Xuneng > > Is it worth/possible in recursive calls of ginScanToDelete() to free > > allocated myStackItem->child after processing all children of the > > current level, when they are not needed anymore? > > Previously to this patch, palloc-ed "me" variable also was't freed at > > recursion levels. > > Freeing/reallocating it per subtree would add churn and make the > lifetime rules harder to reason about without meaningful memory > savings (the number of nodes is bounded by tree depth, not number of > pages). We currently free the chain once after ginScanToDelete() > returns in ginVacuumPostingTree(), which matches the natural lifetime > boundary I proposed not freeing child when child iteration is complete. They indeed can be reused. I proposed cleaning children when "my" iteration is complete. At that time all the children iterations are completed and not needed when we return level up. Regards, Pavel Borisov Supabase
Commits
-
Rework ginScanToDelete() to pass Buffers instead of BlockNumbers.
- fa6f2f624c01 19 (unreleased) landed
-
Fix deadlock between ginDeletePage() and ginStepRight()
- e14641197a56 13.0 cited