From: | PFC <lists(at)peufeu(dot)com> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "C Storm" <christian(dot)storm(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: pgmemcache |
Date: | 2006-04-12 07:19:18 |
Message-ID: | op.s7vvyggtcigqcu@apollo13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
It would be nice to have ON COMMIT triggers for this use.
However you can emulate ON COMMIT triggers with a modification of the
memcache update process :
- A standard trigger sends the data to update to memcache
- The trigger also sends the PID
- Instead of being used immediately, this data is kept in a buffer
- Notify is issued
On commit :
- postgres sends the NOTIFY signal
- the memcache updater reads the NOTIFY (which embeds the PID I believe)
; it finds the buffered data sent above and uses it to update memcached
On rollback :
- Interesting problem ;)))
OK, it's a kludge. When can we get ON COMMIT triggers ?
> On Tue, Apr 04, 2006 at 12:24:42AM -0700, C Storm wrote:
>> I was wondering if anyone on the list has a successful installation of
>> pgmemcache running
>> that uses LISTEN/NOTIFY to signal a successfully completed transaction,
>> i.e., to get around the fact
>> that TRIGGERS are transaction unaware. Or perhaps any other
>> information regarding a successful
>> deployment of pgmemcache.
>
> The problem with attempting that is that you'd have a window between
> transaction commit and when the cache was invalidated. If that's
> acceptable then it shouldn't be too difficult to set something up using
> LISTEN/NOTIFY like you describe.
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2006-04-12 07:22:52 | Re: FOREIGN KEYS vs PERFORMANCE |
Previous Message | Tom Lane | 2006-04-12 02:56:43 | Re: FOREIGN KEYS vs PERFORMANCE |