| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2011-01-05 02:27:10 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
| Previous Message | Greg Smith | 2011-01-05 01:59:57 | Re: Sync Rep Design |