Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YpjqL-0008Dl-CW for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2015 20:53:29 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YpjqK-0002xg-DN for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2015 20:53:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YpjqH-0002u2-Rq for pgsql-hackers@postgresql.org; Tue, 05 May 2015 20:53:25 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1YpjqD-0000ab-SY for pgsql-hackers@postgresql.org; Tue, 05 May 2015 20:53:24 +0000 Received: from intern.anarazel.de (tmo-096-92.customers.d1-online.com [80.187.96.92]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 23CA8860001; Tue, 5 May 2015 22:53:20 +0200 (CEST) Date: Tue, 5 May 2015 17:40:30 +0200 From: Andres Freund To: Peter Geoghegan Cc: hlinnaka , Jeff Janes , Stephen Frost , Dean Rasheed , Bruce Momjian , Pg Hackers Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 Message-ID: <20150505154030.GI9855@alap3.anarazel.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -0.3 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi, On 2015-04-26 18:02:06 -0700, Peter Geoghegan wrote: > Remaining challenges > ================= One additional thing I'm wondering about is the following: Right now INSERT ... ON CONFLICT NOTHING does not acquire a row level lock on the 'target' tuple. Are we really ok with that? Because in this form ON CONFLICT NOTHING really doesn't guarantee much, the conflicting tuple could just be deleted directly after the check. ISTM we should just acquire the lock in the same way ExecOnConflictUpdate does. In the majority of the cases that'll be what users actually expect behaviourally. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers