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

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

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: heikki(dot)linnakangas(at)enterprisedb(dot)com, simon(at)2ndquadrant(dot)com, marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi, bxzhai2010(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, sfrost(at)snowman(dot)net
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2011-01-05 02:26:20
Message-ID: 4D23D6CC.9010009@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Kevin Grittner wrote:
> Greg Smith  wrote:
>  
>   
>> I could see shipping this with the automatic heavy LOCK TABLE in
>> there.
>>     
>  
> How would you handle or document behavior in REPEATABLE READ
> isolation?  The lock doesn't do much good unless you acquire it
> before you get your snapshot, right?
>   

Hand-wave and hope you offer a suggested implementation?  I haven't 
gotten to thinking about this part just yet--am still assimilating 
toward a next move after the pleasant surprise that this is actually 
working to some degree now.  You're right that turning the high-level 
idea of "just lock the table" actually has to be mapped into exact 
snapshot mechanics and pitfalls before moving in that direction will get 
very far.  I'm probably not the right person to answer just exactly how 
feasibile that is this week though.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

pgsql-hackers by date

Next:From: Greg SmithDate: 2011-01-05 02:27:10
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous:From: Greg SmithDate: 2011-01-05 01:59:57
Subject: Re: Sync Rep Design

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