Re: Postgresql Caching

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "mark(at)mark(dot)mielke(dot)cc" <mark(at)mark(dot)mielke(dot)cc>
Cc: "Anon Mous" <soundami(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgresql Caching
Date: 2006-10-16 14:00:34
Message-ID: b42b73150610160700o36f25ca0p18d623e8ae0e9e5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/15/06, mark(at)mark(dot)mielke(dot)cc <mark(at)mark(dot)mielke(dot)cc> wrote:
> 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.
>
> 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.

use advisory locks for 'race sensitive' data. (or user locks in <
8.2). or, just use tables, becuase you need mvcc, not performance :)

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-10-16 14:10:44 Re: [HACKERS] BUG #2683: spi_exec_query in plperl returns
Previous Message Tom Lane 2006-10-16 14:00:13 Re: BUG #2683: spi_exec_query in plperl returns column names which are not marked as UTF8