On Tue, 5 Mar 2024 at 13:55, Dean Rasheed wrote:
>
> > If I only execute merge , I will get the following error:
> > merge into tgt a using src1 c on a.a = c.a when matched then update
> > set b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute
> > fail
> > ERROR:
[cc'ing Alvaro]
On Tue, 5 Mar 2024 at 10:04, zwj wrote:
>
> If I only execute merge , I will get the following error:
> merge into tgt a using src1 c on a.a = c.a when matched then update set
> b = c.b when not matched then insert (a,b) values(c.a,c.b); -- excute fail
> ERROR: MERGE
Hi??hackers
I may have discovered another issue in the concurrency scenario of
merge, and I am currently not sure if this new issue is related to the
previous one.
It seems that it may also be an issue with the EPQ mechanism in the merge
scenario?
I will provide this test case, hoping it will
On Wed, Feb 28, 2024 at 8:11 PM Dean Rasheed wrote:
>
> On Wed, 28 Feb 2024 at 09:16, jian he wrote:
> >
> > + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
> > +
> > + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod);
> > +
> > + ExecAssignExprContext(estate,
On Wed, 28 Feb 2024 at 09:16, jian he wrote:
>
> + oldcontext = MemoryContextSwitchTo(estate->es_query_cxt);
> +
> + node->as_epq_tupdesc = lookup_rowtype_tupdesc_copy(tupType, tupTypmod);
> +
> + ExecAssignExprContext(estate, >ps);
> +
> + node->ps.ps_ProjInfo =
> +
On Tue, Feb 27, 2024 at 8:53 PM Dean Rasheed wrote:
>
> Attached is a very rough patch. It seemed better to build the
> projection in the executor rather than the planner, since then the
> extra work can be avoided, if EPQ is not invoked.
>
> It seems to work (it passes the isolation tests, and I
On Fri, 23 Feb 2024 at 00:12, Tom Lane wrote:
>
> So after studying this for awhile, I see that the planner is emitting
> a PlanRowMark that presumes that the UNION ALL subquery will be
> scanned as though it's a base relation; but since we've converted it
> to an appendrel, the executor just
I wrote:
> I think that this is a band-aid that's just masking an error in the
> rowmarking logic: it's not doing the right thing for appendrels
> made from UNION ALL subqueries. I've not wrapped my head around
> exactly where it's going off the rails, but I feel like this ought
> to get fixed
Dean Rasheed writes:
> Attached is a patch that prevents UNION ALL subquery pullup in MERGE only.
I think that this is a band-aid that's just masking an error in the
rowmarking logic: it's not doing the right thing for appendrels
made from UNION ALL subqueries. I've not wrapped my head around
On Thu, 22 Feb 2024 at 03:46, zwj wrote:
>
> If I want to get the same results as Oracle, do I need to adjust the lock
> behavior of the update and merge statements?
> If I want to achieve the same results as Oracle, can I achieve exclusive
> locking by adjusting update and merge? Do you
Thanks your reply.
I understand what you mean and have tried to correct this patch.
According to the previous use case, the result obtained is as follows:
id | name | year | xmax | xmin | ctid
+--+--+--+--+---
1 | liuwei | 20 | 0 |
859 | (0,1)
2 | zhangbin |
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> On the face of it, the simplest fix is to tweak is_simple_union_all()
> to prevent UNION ALL subquery pullup for MERGE, forcing a
> subquery-scan plan. A quick test shows that that fixes the reported
> issue.
>
> However, that leaves the
On Tue, 20 Feb 2024 at 14:49, Dean Rasheed wrote:
>
> Also, if the concurrent update were an update of a key
> column that was included in the join condition, the re-scan would
> follow the update to a new matching source row, which is inconsistent
> with what would happen if it were a join to a
On Mon, 19 Feb 2024 at 17:48, zwj wrote:
>
> Hello,
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>This question is about 'merge into'.
>
>When two merge into statements are executed concurrently, I obtain the
> following
On Sun, 4 Feb 2024 at 18:19, zwj wrote:
>
>I found an issue while using the latest version of PG15
> (8fa4a1ac61189efffb8b851ee77e1bc87360c445).
>
>This issue is related to Megre into and other concurrent statements being
> written.
>I obtained different results in Oracle and PG
15 matches
Mail list logo
