On Thu, 2008-10-30 at 08:30 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> 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
> >> happens).
>
> > Augmenting the commit messages seems like the better approach. It allows
> > invalidation messages to be fired as they are read off the xlrec. Still
> > need the additional message type to handle nontransactional
> > invalidation. There are other messages possibly more complex than this
> > already.
>
> I guess I hadn't been paying attention, but: adding syscache inval
> traffic to WAL seems like a completely horrid idea, both from the
> complexity and performance standpoints.
Well, it's coming out fairly simple actually. Can you explain where you
think the performance loss is? My expectation is less than a 0.1% WAL
volume overhead for typical systems. My comment this morning was to say
I've managed to augment the commit record, so we're not even sending
many additional messages.
It also makes much of the Hot Standby patch fairly simple, even if it is
large. Write something to WAL, act on it on the other side. I've paid
very close attention to minimising the effects on both the number of
lock acquisitions and total WAL volume, but having said that I expect
there to be many tuning opportunities.
> 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 being in place. It ain't. Subtransactions make
everything about 5 times more difficult, so it seems pretty scary to me.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
