|
|
|
|
|
|
by jenseng
4613 days ago
|
|
|
This approach works well when you want to cache data from an existing integration database and don't have the luxury of rearchitecting the whole thing. At my previous job, we had a bunch of systems talking to a single database. Some were rails, some were not. We wanted to add memcached to the rails apps via cache-money[1]. That'll handle read-through/write-through caching for vanilla rails stuff, but we had to somehow invalidate the cache for updates that happen outside of ActiveRecord::Base#save (e.g. update_all, or a write from a non-rails system). In the end, we settled upon the same approach[2] as in the article. The trigger-backed cache invalidator was also written in ruby, and knew from rails/cache-money what key(s) needed to be invalidated when it got a notification. IIRC you didn't need to do anything special when you added a new cache key (e.g. cache user lookups by username), since the invalidator would just know what to do. [1] https://github.com/nkallen/cache-money [2] This was actually on 8.4, so unfortunately there was no NOTIFY. Instead, a plpython trigger would send a message to invalidator (persistent tcp conn per pg process), but this had the unfortunate consequences of 1. firing before the commit and 2. firing even in the event of a rollback |
|
|
There was actually, listen/notify was available back in 7.1[0][1], maybe earlier.
No payload until 9.0 though, that would usually be done by storing the payload in a dedicated table and querying that when receiving a notification.
[0] http://www.postgresql.org/docs/7.1/static/sql-listen.html
[1] http://www.postgresql.org/docs/7.1/static/sql-notify.html
edit: found the 6.4 docs, it's there: http://www.postgresql.org/docs/6.4/static/sql-listen.html
edit 2: digging in the release notes, LISTEN/NOTIFY was made to work in Postgres95 Beta 0.03: http://www.postgresql.org/docs/6.4/static/release13262.htm (and was apparently present in a non-working state in previous versions)