Skip site navigation (1) Skip section navigation (2)

Re: ask for review of MERGE

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ask for review of MERGE
Date: 2010-10-24 23:11:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Oct 24, 2010 at 2:50 AM, Martijn van Oosterhout
<kleptog(at)svana(dot)org> wrote:
> Can we please not get MERGE hung up on trying to make it atomic. The
> standard requires no such thing and there are plenty of uses of MERGE
> that don't involve high concurrency updates of the same row by
> different processes. If we want an atomic UPSERT, make that a seperate
> command, MERGE without atomicity is useful enough already.

Really? I don't really see any point in a non-atomic MERGE. Nor in a
non-atomic UPDATE or INSERT or any other operation. The A in ACID is
as important as any other letter.

For that matter if you don't care about atomicity then this is a
problem already solvable easily solvable in the application. Why
bother providing a special command for it. The whole reason to want a
special command is precisely because the database can implement it
atomically more easily and more efficiently than any application

Moreover having a case which is non-atomic and allows inconsistent
results or errors in the face of concurrent updates is a foot-gun.
Someone will come along and try to use it and it will appear to work
in their application but introduce nasty hidden race conditions.


In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2010-10-24 23:16:56
Subject: Re: ask for review of MERGE
Previous:From: Andrew DunstanDate: 2010-10-24 23:05:29
Subject: Re: why does plperl cache functions using just a bool for is_trigger

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group