Re: memcached and PostgreSQL

> While an exception, this is a very real possibility in day to day  
> operations. The absence of any feedback or balancing mechanism between  
> the database and cache makes it impossible to know that they are in sync  
> and even a small error percentage multiplied over time will lead to an  
> ever increasing likelihood of error.

	Sure, but there are applications where it does not matter, and these  
applications are othen loading the database... think about displaying  
forum posts, products list in a web store, and especially category trees,  
top N queries... for all these, it does not matter if the data is a bit  
stale. For instance, a very popular forum will be cached, which is very  
important. In this case I think it is acceptable if a new post does not  
appear instantly.

	Of course, when inserting or updating data in the database, the primary  
keys and other important data should be fetched from the database and not  
the cache, which supposes a bit of application logic (for instance, in a  
forum, the display page should query the cache, but the "post message"  
page should query the database directly).

	Memcache can also save the database from update-heavy tasks like user  
session management. In that case sessions can be stored entirely in memory.

	ON COMMIT triggers would be very useful.

> More dangerous is that this discrepancy will NOT always be apparent  
> because without active verification of the correctness of the cache, we  
> will not know about any errors unless the error grows to an obvious  
> point.

> The errors may cause material damage long before they become obvious.  
> This is a common failure pattern with caches.

	This is why it would be dangerous to fetch referential integrity data  
 from the cache... this fits your "banking" example for instance.