Re: Fix crash when non-creator being an iteration on shared radix tree
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: John Naylor <johncnaylorls@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-12-18T17:59:44Z
Lists: pgsql-hackers
Attachments
- v2-0001-radixtree-Fix-crash-when-non-creator-begins-an-it.patch (application/octet-stream) patch v2-0001
On Tue, Dec 17, 2024 at 11:12 PM John Naylor <johncnaylorls@gmail.com> wrote: > > On Wed, Dec 18, 2024 at 12:49 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > Hi, > > > > I found that a server crashes due to a null-pointer-dereference if a > > process attached to the shared radix tree begins an iteration on it, > > because we don't create the memory context for iter_context at > > RT_ATTACH(). There is no code in the core causing this crash in the > > core since in parallel vacuum, the leader process always creates the > > shared radix tree and begins the iteration. However it could happen in > > external extensions. I've attached the patch to fix it and I think it > > should be backpatched to v17. > > +1 in general, but I wonder if instead the iter_context should be > created within RT_BEGIN_ITERATE -- I imagine that would have less > duplication and would be as safe, but I haven't tried it. Is there > some reason not to do that? I agree that it has less duplication. There is no strong reason I didn't do that. I just didn't want to check 'if (!tree->iter_context)' in RT_BEGIN_ITERATE for simplicity. I've changed the patch accordingly. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Commits
-
radixtree: Fix crash when non-creator begins iteration over shared tree.
- 9af2b3435844 17.3 landed
-
Always use the caller-provided context for radix tree leaves
- 3e70da2781e8 18.0 landed
-
Get rid of radix tree's general purpose memory context
- e8a6f1f908d0 18.0 landed
-
Use caller's memory context for radix tree iteration state
- 960013f2a1f9 18.0 landed