Re: Listen / Notify - what to do when the queue is full
От | Simon Riggs |
---|---|
Тема | Re: Listen / Notify - what to do when the queue is full |
Дата | |
Msg-id | 1266515921.7341.10035.camel@ebony обсуждение исходный текст |
Ответ на | Re: Listen / Notify - what to do when the queue is full (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Listen / Notify - what to do when the queue is full
Re: Listen / Notify - what to do when the queue is full |
Список | pgsql-hackers |
On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote: > Joachim Wieland <joe@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
В списке pgsql-hackers по дате отправления: