Thanks for answers!

> But please, detalize how Slony uses LISTEN/NOTIFY and why, if it uses
> > LISTEN/NOTIFY, it still generates poll queries instead of sitting and
> > waiting for a NOTIFY event. I cannot find this information in the Slony
> > documentation.
>
> Which version are you using?  In the past, we found that too much
> reliance on LISTEN/NOTIFY tended to cause bloat in pg_listener and a
> different set of problems.  So 1.2.x reduced that cost, at the
> expense of additional polls.  Those polls should be cheap.  I'm
> mostly worried about. . .

We use 1.2.4.
Poll is cheap if there is a small number of slaves. But if I have 10 or more
slaves...
By the way, if the poll is used now, what role still have LISTEN/NOTIFY?

> possible without bombing the master by polling queries. E.g. lag 0.2s is
> > allowed, but 5 polling queries per second is too much.
> . . .this.  Why is it too much?  Anyway, if that's too much, then why
> not set the lag to the level you'd find acceptable?

Assume that I set the lag to 1s and have 10 slaves.
So, there are 10 polling queries per second, and the slave updation lag is >
1s (I need 0.2s lag and no more ideally).

All this causes that if I use Slony in the production website, I have to
bind the user's session to the master database for the time of 1-2 seconds
after each user's update. Assume that a user fills some form and posts it to
the script on a server. This script processes the form, adds information to
the database and redirects to the resulting page (in most cases this page
contains some part of added data). After such redirect I cannot use a Slave
for 1-2 seconds because of the updation lag, so I have to use Master
connection. And Master loading grows. The more we reduce ths updation lag,
the less Master is loaded by such user's queries, that's why I want to
decrease the lag as much as possible.

I have the following idea: write 2 stored functions in C (as pg contrib):

- ipc_listen(name): blocks until the signal is received
- ipc_notify(name): sends a signal

They are analogs of LISTEN/NOTIFY, but use standard IPC instead of
pg_listener. Then I:

- create a SELECT RULE and make all the slave readings from sl_log_status
wait for ipc_listen('log_status');
- create a TRIGGER and make all writings to sl_log_status to call
ipc_notify('log_status')

So, if anybody reads from sl_log_status, it blocks until anything is written
to sl_log_status. Seems it will be fully transparent for Slony, but
decreases the amount of polling queries. (It is an idea only, practical
implementation may need to be more detailed.) What do you think about it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070514/=
3568e379/attachment.htm