| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
| Cc: | Tom Lane *EXTERN* <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Feedback on getting rid of VACUUM FULL |
| Date: | 2009-09-18 07:28:26 |
| Message-ID: | 1253258906.9666.337.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2009-09-18 at 08:50 +0200, Albe Laurenz wrote:
> Tom Lane wrote:
> > > I don't see any reason why not breaking the user visible behavior of
> > > tuples CTID between any two major releases,
> >
> > > Am I completely wet here?
> >
> > Completely. This is a user-visible behavior that we have encouraged
> > people to rely on, and for which there is no easy substitute.
>
> I second that: it would hurt to lose this generic technique for
> optimistic locking.
CTIDs don't help with optimistic locking, though it seems they can.
If you don't hold open the transaction then someone else can update the
row. That sounds good, but because of HOT it is possible that the same
CTID with the same PK value occupies that exact CTID value when you
return to check it. You think row has not been updated so you perform
your update, but it has been updated, so you overwrite previous data -
data loss. Actually worse, sporadic data loss because of race
conditions.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2009-09-18 07:55:29 | Re: ECPG patchset |
| Previous Message | Boszormenyi Zoltan | 2009-09-18 07:19:25 | Re: ECPG patchset |