Re: pgmemcache - Mailing list pgsql-performance

From PFC
Subject Re: pgmemcache
Date
Msg-id op.s7vvyggtcigqcu@apollo13
Whole thread Raw
In response to Re: pgmemcache  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: pgmemcache  (Josh Berkus <josh@agliodbs.com>)
List 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.



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: FOREIGN KEYS vs PERFORMANCE
Next
From: PFC
Date:
Subject: Re: FOREIGN KEYS vs PERFORMANCE