Re: Extending SMgrRelation lifetimes
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-01-31T10:37:22Z
Lists: pgsql-hackers
On 31/01/2024 10:54, Thomas Munro wrote: > On Wed, Nov 29, 2023 at 1:42 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> I spent some more time digging into this, experimenting with different >> approaches. Came up with pretty significant changes; see below: > > Hi Heikki, > > I think this approach is good. As I wrote in the first email, I had > briefly considered reference counting, but at the time I figured there > wasn't much point if it's only ever going to be 0 or 1, so I was > trying to find the smallest change. But as you explained, there is > already an interesting case where it goes to 2, and modelling it that > way removes a weird hack, so it's a net improvement over the unusual > 'owner' concept. +1 for your version. Are there any further tidying > or other improvements you want to make? Ok, no, this is good to go then. I'll rebase, fix the typos, run the regression tests again, and push this shortly. Thanks! -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Give SMgrRelation pointers a well-defined lifetime.
- 21d9c3ee4ef7 17.0 landed
-
Remove some obsolete smgrcloseall() calls.
- 6a8ffe812d19 17.0 landed
-
Don't try to open visibilitymap when analyzing a foreign table
- 049ef3398d05 17.0 landed
-
Invalidate smgr_targblock in smgrrelease().
- d23e60e6673a 15.5 landed
- 6337e994e897 16.0 landed
- 81e36d3e0df8 17.0 landed