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, 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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers