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

Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, 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: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2011-01-03 16:35:18
Message-ID: 4D21FAC6.3020502@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 03.01.2011 18:29, Simon Riggs wrote:
> On Mon, 2011-01-03 at 18:08 +0200, Heikki Linnakangas wrote:
>
>> It works in read committed mode, because you acquire a new snapshot
>> after the LOCK TABLE, and anyone else who modified the table must commit
>> before the lock is granted. In serializable mode you get a serialization
>> error.
>
> If its not safe without this
>
> LOCK TABLE ... IN SHARE ROW EXCLUSIVE MODE
>
> then we should do that automatically, and document that.

No we should not. The SQL standard doesn't require that, and it would 
unnecessarily restrict concurrent updates on unrelated rows in the table.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-01-03 16:36:25
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous:From: Stephen FrostDate: 2011-01-03 16:29:46
Subject: Re: Scanning pg_tablespace from walsender

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