On Mon, 16 Oct 2006, [EMAIL PROTECTED] wrote:
> On Sun, Oct 15, 2006 at 06:33:36PM -0700, Jeremy Drake wrote:
> > > 2) When updating a PostgreSQL record, I updated the memcache record
> > > to the new value. If another process comes along in parallel before
> > > I commit, that is still looking at an older view, cross-referencing
> > > may not work as expected.
> > Shouldn't you be able to use 2-stage commit for this? Prepare to commit,
> > update the memcache record, then commit? Or am I thinking of something
> > else?
>
> Two stage commits makes the window of error smaller, it can't eliminate it.
Right, I was thinking there was still some raciness there. I think what I
remembered is that if you updated the cache and then the transaction
failed (or rolled back for whatever reason) later on, the cache would have
data that was never committed. The two-phase commit thing is intended to
deal with that eventuality. Which is also a possibility for a consistency
issue.
--
Oh, I have slipped the surly bonds of earth,
And danced the skies on laughter silvered wings;
Sunward I've climbed and joined the tumbling mirth
Of sun-split clouds and done a hundred things
You have not dreamed of --
Wheeled and soared and swung
High in the sunlit silence.
Hovering there
I've chased the shouting wind along and flung
My eager craft through footless halls of air.
Up, up along delirious, burning blue
I've topped the wind-swept heights with easy grace,
Where never lark, or even eagle flew;
And, while with silent, lifting mind I've trod
The high untrespassed sanctity of space,
Put out my hand, and touched the face of God.
-- John Gillespie Magee Jr., "High Flight"
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
