Skip site navigation (1) Skip section navigation (2)

Re: Listen / Notify - what to do when the queue is full

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Arnaud Betremieux <arnaud(dot)betremieux(at)keyconsulting(dot)fr>
Subject: Re: Listen / Notify - what to do when the queue is full
Date: 2010-02-15 20:00:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Joachim Wieland <joe(at)mcknight(dot)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

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-15 20:03:21
Subject: Re: Avoiding bad prepared-statement plans.
Previous:From: Robert HaasDate: 2010-02-15 19:58:52
Subject: Re: Explain buffers display units.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group