Обсуждение: NOTIFY/LISTEN on read-only slave?
Our documentation says listen/notify will return an error if executed on the hot standby server: o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables With the listen/notify system now implemented in memory, is this still true? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Our documentation says listen/notify will return an error if executed on
> the hot standby server:
> o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
> With the listen/notify system now implemented in memory, is this still
> true?
The explanation is wrong, but it's still disallowed.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Our documentation says listen/notify will return an error if executed on > > the hot standby server: > > > o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables > > > With the listen/notify system now implemented in memory, is this still > > true? > > The explanation is wrong, but it's still disallowed. Thanks, implemented detail removed, restriction retained. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > >> Our documentation says listen/notify will return an error if executed on >> the hot standby server: >> >> o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables >> >> With the listen/notify system now implemented in memory, is this still >> true? >> > > The explanation is wrong, but it's still disallowed. > What's the actual reason for the restriction then? I did a whole proofreading round on the HS documentation the other day and am working on a patch to clean up everything I found, can add better notes about this to it. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg Smith wrote: > Tom Lane wrote: >> The explanation is wrong, but it's still disallowed. >> > What's the actual reason for the restriction then? I did a whole > proofreading round on the HS documentation the other day and am > working on a patch to clean up everything I found, can add better > notes about this to it. Will answer my own question now, from the commit log: "There is not yet any facility for HS slaves to receive notifications generated on the master, although such a thing is possible in future." I'll include that detail in the doc patch I'm working on. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg Smith wrote: > Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > >> Our documentation says listen/notify will return an error if executed on > >> the hot standby server: > >> > >> o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables > >> > >> With the listen/notify system now implemented in memory, is this still > >> true? > >> > > > > The explanation is wrong, but it's still disallowed. > > > > What's the actual reason for the restriction then? I did a whole > proofreading round on the HS documentation the other day and am working > on a patch to clean up everything I found, can add better notes about > this to it. Oops, I did cleanup on the HS docs all day today in response to a doc patch that was posted in December. How extensive are your changes? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Oops, I did cleanup on the HS docs all day today in response to a doc > patch that was posted in December. How extensive are your changes? > Not very--wording improvements, typos, some technical clarification after quizzing Simon on internals that were described in a fuzzy way. I'll just wait until I see your commit and then rebase on top of that, no big deal. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg Smith wrote: > Bruce Momjian wrote: > > Oops, I did cleanup on the HS docs all day today in response to a doc > > patch that was posted in December. How extensive are your changes? > > > > Not very--wording improvements, typos, some technical clarification > after quizzing Simon on internals that were described in a fuzzy way. > I'll just wait until I see your commit and then rebase on top of that, > no big deal. Great, patch applied. Hopefully there are not too many conflicts on your end. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Greg Smith <greg@2ndquadrant.com> writes:
> What's the actual reason for the restriction then?
Well, NOTIFY doesn't seem very sensible for a read-only slave to
execute: it can't change the database state so there's nothing for
it to notify about. Ideally we should allow slave sessions to LISTEN
to notify events that were generated on the master, though. The recent
patch eliminates the major impediments to doing that, but we're still
shy of some infrastructure to do it --- mainly, some code to push
notify events through the WAL stream. (Presumably this would have to be
something you could enable or disable, because WAL-logging notifies
on a machine that wasn't an HS master would be a large and very useless
performance overhead.)
regards, tom lane
Tom Lane wrote: > Greg Smith <greg@2ndquadrant.com> writes: > > What's the actual reason for the restriction then? > > Well, NOTIFY doesn't seem very sensible for a read-only slave to > execute: it can't change the database state so there's nothing for > it to notify about. Ideally we should allow slave sessions to LISTEN > to notify events that were generated on the master, though. The recent > patch eliminates the major impediments to doing that, but we're still > shy of some infrastructure to do it --- mainly, some code to push > notify events through the WAL stream. (Presumably this would have to be > something you could enable or disable, because WAL-logging notifies > on a machine that wasn't an HS master would be a large and very useless > performance overhead.) I assumed people would want to do listen/notify on the slave only, or is there no good use for that? I don't see passing notify information from the master to the slave as useful. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> I assumed people would want to do listen/notify on the slave only, or is
> there no good use for that? I don't see passing notify information from
> the master to the slave as useful.
You apparently haven't been reading the thread where we were discussing
the listen/notify patch. The primary use-case for LISTEN/NOTIFY is to
let clients cache information about the state of the database and then
notify each other when one of them does something that invalidates
others' cached state. A read-only slave client has just as much use for
caching such info as one connected directly to the master, and hence
just as much need to hear about it when someone on the master changes
the database state in a way that invalidates its cache. (This also
explains why NOTIFY on the slave side is *not* interesting: there is no
way for a slave session to do anything that would invalidate anyone
else's cached view of the database.)
regards, tom lane