Re: [HACKERS] MERGE SQL Statement for PG11 - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id 54c4e625-4f08-ef7a-478f-3cca3823d2b6@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Responses Re: [HACKERS] MERGE SQL Statement for PG11  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On 2018/03/23 3:42, Pavan Deolasee wrote:
> A slightly improved version attached. Apart from doc cleanup based on
> earlier feedback, fixed one assertion failure based on Rahila's report.
> This was happening when target relation is referenced in the source
> subquery. Fixed that and added a test case to test that situation.
> 
> Rebased on current master.

I tried these patches (applied 0002 on top of 0001).  When applying 0002,
I got some apply errors:

The next patch would create the file
src/test/isolation/expected/merge-delete.out,
which already exists!  Assume -R? [n]

I managed to apply it by ignoring the errors, but couldn't get make check
to pass; attached regressions.diffs if you want to take a look.

Btw, is 0001 redundant with the latest patch on ON CONFLICT DO UPDATE
thread?  Can I apply just 0002 on top of that patch?  So, I tried that --
that is, skipped your 0001 and instead applied ON CONFLICT DO UPDATE
patch, and then applied your 0002.  I had to fix a couple of places to get
MERGE working correctly for partitioned tables; attached find a delta
patch for the fixes I made, which were needed because I skipped 0001 in
favor of the ON CONFLICT DO UPDATE patch.  But the regression test failure
I mentioned above didn't go away, so it seems to have nothing to do with
partitioning.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Michael Paquier
Date:
Subject: Re: [PoC PATCH] Parallel dump to /dev/null