No, of course I meant NOT global readers blocking. I DO NOT NEED zero lag. I
need only SHORT lag (e.g. 0.1 s), BUT without bombing the Master by polling
queries when the number of slaves is 20 (20/0.1 =3D 200 queries/s is too
much!).

I'll explain everything from scratch. Suppose we have 2 stored functions:

1. ipc_listen(): blocks the current session (session!) until somebody called
ipc_notify().
2. ipc_notify(): send a message to ALL who are waiting inside blocking
ipc_listen() call.

We could write these functions as postgres contrib (in C), using named
pipes. It is about 50 lines of C code, no more. Note that these functions DO
NOT USE standart postgres LISTEN/NOTIFY mechanism, so the do not bloat
pg_listeners table at all.

Now let's consider the following algorythm.

1. Slave is always connected to the master, so it runs ipc_listen(). This
call blocks its session.
2. Master, after it modifies an event table, in addition calls ipc_notify()
to make all slaves to wake up.
3. All the slaves wake up from ipc_listen() (exit from this stored function)
and continue their work: read events from the table as usual etc. - as it
realized in Slony now.
4. On the next round all the slaves begin from (1).

This algorythm avoids a lot of polling queries, because we generate next
polling query only if the previous one is finished. It also reduces the lag
between master and slave synchronization, because changes are spreaded in a
short time after the master is added a row to its event table.

So, the only difference from today's Slony implementation is to call
ipc_listen() before each polling query and run ipc_notify() just after an
event were inserted to the master's table.

I do not understand why this solution is inappropriate. Please explain.


On 5/14/07, Andrew Sullivan <ajs at crankycanuck.ca> wrote:
>
> On Mon, May 14, 2007 at 05:42:38PM +0400, Dmitry Koterov wrote:
> > >
> > >> >> So, if anybody reads from sl_log_status, it blocks until anything
> is
> > >> >written
> > >> >> to sl_log_status.
>
> > Hmmm... But in postgres read operations never blocks other operations
> (by
> > default) because of versioning. So, while all the replicas are blocked
> > waiting for a new event, they are still able to process a lot of read
> > queries coming from the site.
>
> I must misunderstand you, then.  What you wrote (above) is that
> you're going to block readers until something writes.  That suggests
> to me that you're taking some sort of read-blocking lock (you can do
> that: LOCK TABLE IN ACCESS EXCLUSIVE MODE will in fact block
> everything).
>
> I guess I still don't understand how any of this helps you, though.
>
> A
>
> --
> Andrew Sullivan  | ajs at crankycanuck.ca
> The plural of anecdote is not data.
>                 --Roger Brinner
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070514/=
86cf974f/attachment.htm