Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TthVq-0007MQ-At for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Jan 2013 16:31:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TthVp-0006Ck-FZ for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Jan 2013 16:31:21 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TthVo-0006Cf-I6 for pgsql-hackers@postgresql.org; Fri, 11 Jan 2013 16:31:20 +0000 Received: from moutng.kundenserver.de ([212.227.126.186]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TthVn-0006KS-8V for pgsql-hackers@postgresql.org; Fri, 11 Jan 2013 16:31:19 +0000 Received: from anarazel.de (p5DDC594E.dip.t-dialin.net [93.220.89.78]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MMrhT-1TtOWr2sUJ-008ToP; Fri, 11 Jan 2013 17:31:14 +0100 Received: by anarazel.de (Postfix, from userid 1000) id ED0221C0177; Fri, 11 Jan 2013 17:31:13 +0100 (CET) Date: Fri, 11 Jan 2013 17:31:13 +0100 From: Andres Freund To: Alvaro Herrera Cc: Erik Rijkers , Kevin Grittner , pgsql-hackers@postgresql.org Subject: Re: foreign key locks Message-ID: <20130111163113.GD6049@awork2.anarazel.de> References: <20121129152326.69330@gmx.com> <20121129160220.GA4942@alvh.no-ip.org> <20121129161654.GB4942@alvh.no-ip.org> <20121228204847.GD4150@alvh.no-ip.org> <20130110210040.GB4110@alvh.no-ip.org> <20130110212218.GE4329@awork2.anarazel.de> <20130111151147.GB4208@alvh.no-ip.org> <20130111151930.GB6049@awork2.anarazel.de> <20130111161049.GD4208@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130111161049.GD4208@alvh.no-ip.org> X-Provags-ID: V02:K0:egffwr1m5LYcA4McAoTW+zOzRIp1l+3U5ifesg0CeTP ypF3yDFAjhKmQVH07R1N3Ab1y2TmlYr/MQT/ebJa25iPgL3pc3 QVY8+SGOpUVXIa2Wl4c1Z5OMcvYngEJb/jdgtDVjFmv84r/g45 EfcHeKzHKOzg0GPSrWNM05Oc1i+innfRTn63YCD3Cr7iX+i6/L C3BPPS7p4tyQlrXaihc/zf4hSce4dtgSFyO90+YbCgUinS/aml 40BRJyFJOMdfKNoobsYWeBcCgbpYmGec1v6ubRnGaQEASE/1rh L2SdDHhhPs5Ll5+bHYqAvwEAV49i6rO2vhhySC1iVZr1BuPDJx S7Y23NWSXMow5FFVlETaveo7MfcC22/YFnIvbwGiZ X-Pg-Spam-Score: -1.9 (-) 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 On 2013-01-11 13:10:49 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > No, I was thinking about an update without triggers present. > > > > T0: CREATE TABLE tbl(id serial pk, name text unique, data text); > > T1: BEGIN; -- read committed > > T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id = 1 */ > > T2: BEGIN; -- read committed > > T2: UPDATE tbl SET name = 'blarg', data = 'blarg' WHERE id = 1; /* no key update, waiting */ > > T1: COMMIT; > > T2: /* UPDATE follows to updated row, due to the changed name its a key update now */ > > > > Does that make sense? > > So I guess your question is "is T2 now holding a TupleLockExclusive > lock?" To answer it, I turned your example into a isolationtester spec: Great! I reread the code and it does make sense the way its implemented now. I misremembered something... I vote for adding that spectest including some appropriate permutations. FWIW: Looks good to me. It could use another pair of eyes, but I guess that will have to come by being used. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers