Re: Postgresql Caching

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: mark(at)mark(dot)mielke(dot)cc
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Anon Mous <soundami(at)yahoo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgresql Caching
Date: 2006-10-16 01:33:36
Message-ID: Pine.BSO.4.64.0610151829560.18508@resin.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 15 Oct 2006, mark(at)mark(dot)mielke(dot)cc wrote:

> On Sun, Oct 15, 2006 at 08:31:36PM +0530, Merlin Moncure wrote:
> > On 10/15/06, Anon Mous <soundami(at)yahoo(dot)com> wrote:
> > > Would it be possible to combine a special memcache implementation of
> > > memcache with a Postgresql interface wrapper?
> > have you seen
> > http://people.freebsd.org/~seanc/pgmemcache/
>
> Interesting. I note that they don't address the view consistency
> problem any better than an application using memcached directly.
> And that's the real problem with memcached, and why people are
> tempted to 'indulge' by relying on PostgreSQL. Some people value
> the consistency. Others don't. memcached, whether application-side,
> or whether automatically invoked by triggers (pgmemcache) is a
> decision to ignore the consistency.
>
> Using memcache, I've had problems with consistency brought right to
> the front. Both of these have failed me:
>
> 1) When updating a PostgreSQL record, I invalidate the memcache record.
> If another process comes along in parallel before I commit, notices
> that the memcache record is invalidated, it queries the data from
> SQL, and updates the memcache record back to the old value. :-(
>
> 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?

> I'm currently settled on 2), but setting a short timeout (5 seconds) on
> the data. Still an imperfect compromise between speed and accuracy, but
> it isn't causing me problems... yet.

--
Fortune's Real-Life Courtroom Quote #32:

Q: Do you know how far pregnant you are right now?
A: I will be three months November 8th.
Q: Apparently then, the date of conception was August 8th?
A: Yes.
Q: What were you and your husband doing at that time?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Harvell F 2006-10-16 01:58:35 Re: Postgresql Caching
Previous Message Craig A. James 2006-10-16 00:25:31 Re: Hints proposal