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

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?
-Kevin

Kevin Grittner wrote: <blockquote cite="mid:4D22B8800200002500038F93@gw.wicourts.gov" type="cite"><pre wrap="">Greg
Smith wrote: </pre><blockquote type="cite"><pre wrap="">I could see shipping this with the automatic heavy LOCK TABLE
in
there.   </pre></blockquote><pre wrap=""> 
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? </pre></blockquote><br /> 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
thepleasant 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
directionwill get very far.  I'm probably not the right person to answer just exactly how feasibile that is this week
though.<br/><br /><pre class="moz-signature" cols="72">-- 
 
Greg Smith   2ndQuadrant US    <a class="moz-txt-link-abbreviated"
href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>  Baltimore, MD
 
PostgreSQL Training, Services and Support        <a class="moz-txt-link-abbreviated"
href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
"PostgreSQL 9.0 High Performance": <a class="moz-txt-link-freetext"
href="http://www.2ndQuadrant.com/books">http://www.2ndQuadrant.com/books</a>
</pre>