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
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 |