Listen / Notify - what to do when the queue is full
in [PgSql]
|
From: Tom Lane on 15 Feb 2010 15:00 Joachim Wieland <joe(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 15 Feb 2010 16:36 On Sun, 2010-02-14 at 22:44 +0000, Simon Riggs wrote: > * We also discussed the idea of having a NOTIFY command that would work > from Primary to Standby. All this would need is some code to WAL log the > NOTIFY if not in Hot Standby and for some recovery code to send the > NOTIFY to any listeners on the standby. I would suggest that would be an > option on NOTIFY to WAL log the notification: > e.g. NOTIFY me 'with_payload' FOR STANDBY ALSO; My first reaction is that it should not be optional. If we allow a slave system to LISTEN on a condition, what's the point if it doesn't receive the notifications from the master? Cache invalidation seems to be the driving use case for LISTEN/NOTIFY. Only the master can invalidate the cache (as Tom points out downthread); and users on the slave system want to know about that invalidation if they are explicitly listening for it. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 17 Feb 2010 00:24 Simon Riggs <simon(a)2ndQuadrant.com> writes: > * Don't really like pg_listening() as a name. Perhaps pg_listening_to() > or pg_listening_on() or pg_listening_for() or pg_listening_channels() or > pg_listen_channels() BTW, I used pg_listening_channels() for that. > * I think it's confusing that pg_notify is both a data structure and a > function. Suggest changing one of those to avoid issues in > understanding. "Use pg_notify" might be confused by a DBA. I didn't change that. The data structure is PGnotify, which seems enough different from pg_notify to not be a real serious problem. There is a duplication with the $PGDATA subdirectory pg_notify/, but that one is not a user-facing name, so I thought it wasn't really an issue. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Greg Sabino Mullane" on 16 Feb 2010 11:02 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > * We also discussed the idea of having a NOTIFY command that > would work from Primary to Standby. Just curious, what's a use case for this? - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201002161102 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkt6wZ4ACgkQvJuQZxSWSsjrYwCfSWvHlTBFT/fIYcBToX9C57GO toAAoOLQhBj6NdVTayaVtRH8L7nk16qM =LBAH -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 16 Feb 2010 13:22
On Tue, 2010-02-16 at 16:02 +0000, Greg Sabino Mullane wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > * We also discussed the idea of having a NOTIFY command that > > would work from Primary to Standby. > > Just curious, what's a use case for this? If you have some kind of cache above the DBMS, you need to invalidate it when a part of the database is updated. It makes sense that every reader would want to know about the update, not just those connected to the master. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |