From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, kristianlejao(at)gmail(dot)com |
Subject: | Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c |
Date: | 2025-09-18 00:24:49 |
Message-ID: | aMtRUQqnowiYFIha@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 17, 2025 at 07:42:36PM +0900, Etsuro Fujita wrote:
> The test case you showed upthread and added to the patch is useful, so
> I think we should add it as well, but my question about it is: is it
> really a good idea to use injection points?
> Why don't you just use BEGIN/COMMIT statements like this:
>
> -- session 1
> begin isolation level read committed;
> update a set i = i + 1;
>
> -- session 2
> begin isolation level read committed;
> select a.i,
> (select 1 from b, c where a.i = b.i and b.i = c.i)
> from a
> for update; -- waits for the transaction in session 1 to complete
>
> -- session 1
> commit;
>
> -- session 2
> select a.i,
> (select 1 from b, c where a.i = b.i and b.i = c.i)
> from a
> for update; -- produces results after doing an EvalPlanQual recheck
> i | ?column?
> ---+----------
> 2 |
> (1 row)
>
> Again, my apologies for the late response.
As far as I can see, this causes the SELECT FOR UPDATE of session 2
that's waiting for the commit of session 1 to crash, if we don't have
the fix, of course. Removing the dependency with injection points is
nice if we don't require it, so we can just tweak the isolation test
proposed upthread to use the same schema, but the queries you are
suggesting.
As a whole, +1 for your suggestion.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2025-09-18 01:33:37 | Re: BUG #19056: ExecInitPartitionExecPruning segfault due to NULL es_part_prune_infos |
Previous Message | Euler Taveira | 2025-09-17 22:34:56 | Re: Read Replica termination occurs when its max_active_replication_origins setting is lower than the primary |