Rahila Syed 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 t
Hi,
So here's a v4 with the test restored.
>
I tested this patch, it fixes the issue reported. It passes Github CI tests.
> already does that, so the only new assert would be in
> MemoryContextCreate.
+1 for adding the assertion to increase the chances of this bug being
caught by memory cont
I wrote:
> ... An obvious candidate is subscription/t/100_bugs.pl, but
> the test failed there for lack of access to the test_decoding plugin.
> Perhaps we could use another plugin, but I didn't try hard.
Ah, I realized we could just use pgoutput, since the test doesn't
actually do anything that w
Anthonin Bonnefoy writes:
> I've updated the patch with another approach:
I got back to looking at this today. I still don't like very much
about it. After thinking for awhile, I concur that we want to create
the cmd_context under TopMemoryContext, but I think we can make things
a great deal si
I've updated the patch with another approach:
0001: This sets the MemoryContext type to T_Invalid just before adding
it to the aset freelist, allowing to distinguish between a
MemoryContext that was placed in the freelist and shouldn't be used,
and a valid one. The existing MemoryContextIsValid ch
On Tue, Mar 11, 2025 at 10:26 AM Anthonin Bonnefoy
wrote:
> --- a/src/backend/utils/mmgr/mcxt.c
> +++ b/src/backend/utils/mmgr/mcxt.c
> @@ -527,6 +527,7 @@ MemoryContextDeleteOnly(MemoryContext context)
>
> context->methods->delete_context(context);
>
> + context->type = T_Invalid;
>
On Tue, Mar 11, 2025 at 1:09 AM Michael Paquier wrote:
> It seems to me that you mean 1afe31f03cd2, no?
Yes, that was a bad copy/paste from me.
On Tue, Mar 11, 2025 at 2:13 AM Tom Lane wrote:
>
> I dunno about this patch: it seems to me it's doing things exactly
> backwards, namely trying to re
Michael Paquier writes:
> On Mon, Mar 10, 2025 at 09:07:59AM +0100, Anthonin Bonnefoy wrote:
>> The issue seems to have been introduced by 2129d184a206c when
>> transactionState->priorContext was added and is only present in HEAD.
> It seems to me that you mean 1afe31f03cd2, no?
I dunno about th
On Mon, Mar 10, 2025 at 09:07:59AM +0100, Anthonin Bonnefoy wrote:
> The issue seems to have been introduced by 2129d184a206c when
> transactionState->priorContext was added and is only present in HEAD.
It seems to me that you mean 1afe31f03cd2, no?
--
Michael
signature.asc
Description: PGP sign
The issue seems to have been introduced by 2129d184a206c when
transactionState->priorContext was added and is only present in HEAD.
Hi,
While running some tests with logical replication, I've run in a
situation where a walsender process was stuck in an infinite loop with
the following backtrace:
#0 in MemoryContextDelete (...) at ../src/backend/utils/mmgr/mcxt.c:474
#1 in exec_replication_command (cmd_string=... "BEGIN") at
11 matches
Mail list logo
