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 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? 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers