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: | 12254.1266264016@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-02-15 20:03:21 | Re: Avoiding bad prepared-statement plans. |
Previous Message | Robert Haas | 2010-02-15 19:58:52 | Re: Explain buffers display units. |