Re: Memory context can be its own parent and child in replication command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rahila Syed <rahilasyed90(at)gmail(dot)com>
Cc: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory context can be its own parent and child in replication command
Date: 2025-04-21 16:23:23
Message-ID: 762220.1745252603@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rahila Syed <rahilasyed90(at)gmail(dot)com> writes:
> +1 for adding the assertion to increase the chances of this bug being
> caught by memory context infrastructure.

I verified that an assertion inside MemoryContextCreate would catch
this bug, so I added one (in 5ec8b01c3), and then pushed the main
fix at 80b727eb9.

> I had the following comment.

> Why do we do this:
> - MemoryContext old_context;
> + MemoryContext old_context = CurrentMemoryContext;
> Instead of implementing it as done in the previous version of this code,
> i.e.
> old_context = MemoryContextSwitchTo(cmd_context);

Because capturing old_context at that point is too late. The crux
of the bug is exactly that SnapBuildClearExportedSnapshot may have
changed CurrentMemoryContext. We could have avoided that by
reordering the code, or done something like what Anthonin did in v02.
But this way is perfectly idiomatic IMO. There are some dozens of
similar usages elsewhere in our code, and it makes very sure that
old_context captures the caller's context even if we rearrange things
some more inside exec_replication_command.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-04-21 16:29:40 Cygwin support
Previous Message Nathan Bossart 2025-04-21 15:55:52 Re: Large expressions in indexes can't be stored (non-TOASTable)