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 invalidat
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
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
> >
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 i
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
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 me
