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

From Simon Riggs
Subject Re: [HACKERS] MERGE SQL Statement for PG11
Date
Msg-id CANP8+jLzhsmvL7fVgikCUR-ZhUCZ3JnMCGjgS49uTsCzvuNCBw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] MERGE SQL Statement for PG11  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] MERGE SQL Statement for PG11
Re: [HACKERS] MERGE SQL Statement for PG11
List pgsql-hackers
On 30 January 2018 at 16:27, Robert Haas <robertmhaas@gmail.com> wrote:

> As far as I am able to understand, the substantive issue here is what
> to do when we match an invisible tuple rather than a visible tuple.
> The patch currently throws a serialization error on the basis that you
> (Simon) thought that's what was previously agreed.

Correct. We discussed this and agreed point (3) below

> 3. Implement MERGE, but without attempting to avoid concurrent ERRORs (Peter)
>
> 4. Implement MERGE, while attempting to avoid concurrent ERRORs in
> cases where that is possible.

Acting in good faith, in respect of all of your wishes, I implemented
exactly that and not what I had personally argued in favour of.

> Peter is arguing
> that we don't normally issue a serialization error at READ COMMITTED
> (which I think is true) and proposed that we instead try to INSERT.

Which IMHO is case 4 since it would avoid a concurrent ERROR. This
meets exactly my original implementation goals as clearly stated on
this thread, so of course I agree with him and have already said I am
happy to change the code, though I am still wary of the dangers he
noted upthread.

If you now agree with doing that and are happy that there are no
dangers, then I'm happy we now have consensus again and we can
continue implementing MERGE for PG11.

This is a good outcome, thanks, our users will be happy.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: WINDOW RANGE patch versus leakproofness
Next
From: Oliver Ford
Date:
Subject: Re: Add RANGE with values and exclusions clauses to the Window Functions