Query (3) will be run in the future, of course, and STATE for it is got from
the past. So, it could happen. We do not need the time-machine to go forward
in time with usual speed. :-)

On 5/17/07, Christopher Browne <cbbrowne at ca.afilias.info> wrote:
>
> "Dmitry Koterov" <dmitry at koterov.ru> writes:
> > Thanks!
> > Seems it is what I was looking for:
> > 1. Current state of the Master:
> > master# STATE :=3D (select st_last_event from _cluster.sl_status limit =
1)
>
> Sounds good!
>
> > 2. Current slave ID:
> > slave# SLAVE_ID :=3D (select _cluster.getlocalnodeid('_cluster'));
>
> Yes, that would be how to determine it...
>
> > 3. If the slave is more up-to-date than master:
> > master# (select min(st_last_received) from _cluster.sl_status where
> st_received =3D SLAVE_ID) >=3D STATE
>
> It should never be possible for a subscriber to be more up to date
> than the origin.
>
> Firstly, that logically doesn't make sense.  (At least, when we're not
> in a universe where time travels backwards, objects 'fall' *away* from
> gravity wells, and such...)
>
> Secondly, implementation-wise, it can't happen because the subscriber
> can't ask for events until the origin has actually generated them.
> --
> select 'cbbrowne' || '@' || 'ca.afilias.info';
> <http://dba2.int.libertyrms.com/>
> Christopher Browne
> (416) 673-4124 (land)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20070518/=
bab06940/attachment.htm