On Thu, 2008-10-30 at 10:13 +, Simon Riggs wrote:
On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations
On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit, queue them and then trigger the send at
Simon Riggs [EMAIL PROTECTED] writes:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit, queue them and then trigger the send at commit (if it
On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We can't augment the commit/abort messages because
we must cater for non-transactional invalidations also, plus commit
xlrecs are already complex enough. So we log invalidations prior to
commit,
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
What about using the existing
syscache logic to re-derive inval information from watching the update
operations?
That does sound possible, but it makes some big assumptions about
transactional machinery
Next stage is handling locks and proc interactions. While this has been
on Wiki for a while, I have made a few more improvements, so please read
again now.
Summary of Proposed Changes
---
* New RMgr using rmid==8 = RM_RELATION_ID (which fills last gap)
* Write new WAL
