On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote: > Joachim Wieland <j...@mcknight.de> writes: > > We could probably fake this on the Hot Standby in the following way: > > > We introduce a commit record for every notifying transaction and write > > it into the queue itself. So right before writing anything else, we > > write an entry which informs readers that the following records are > > not yet committed. Then we write the actual notifications and commit. > > In post-commit we return back to the commit record and flip its > > status. > > This doesn't seem likely to work --- it essentially makes commit non > atomic. There has to be one and only one authoritative reference as > to whether transaction X committed.
I thought a bit more about this and don't really understand why we need an xid at all. When we discussed this before the role of a NOTIFY was to remind us to refresh a cache, not as a way of delivering a transactional payload. If the cache refresh use case is still the objective why does it matter whether we commit or not when we issue a NOTIFY? Surely, the rare case where we actually abort right at the end of the transaction will just cause an unnecessary cache refresh. > I think that having HS slave sessions issue notifies is a fairly silly > idea anyway. They can't write the database, so exactly what condition > are they going to be notifying others about? Agreed > What *would* be useful is for HS slaves to be able to listen for notify > messages issued by writing sessions on the master. This patch gets rid > of the need for LISTEN to change on-disk state, so in principle we can > do it. The only bit we seem to lack is WAL transmission of the messages > (plus of course synchronization in case a slave session is too slow > about picking up messages). Definitely a 9.1 project at this point > though. OK -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers