On Tue, 18 Jan 2011 08:04:18 -0500, Steve Singer <ssinger at ca.afilias.info>
wrote:
> On 11-01-18 05:08 AM, Guillaume Lelarge wrote:
>> Hi,
>>
>> I have an issue on Slony 2.0.6 and PostgreSQL 9.0.2. After stopping a
>> slave, waiting for a few minutes, and then starting the slave again,
the
>> sl_status view shows a lag that keeps going up. And even if the lag
keeps
>> going up, replication is working on all slaves. The only way to fix
this
>> is
>> to restart the slon daemons.
>>
>> Is this behaviour expected? AFAICT, it isn't. At least, it doesn't seem
>> so
>> to Peter Geoghegan that asked many times about this issue (see
"sl_status
>> incorrectly reports long event lag", "Error - table id 1 has already
been
>> assigned", "Problem with Slony-I 2.0.2, sl_status persists", "Why does
>> sl_status event lag grow, even though events *are* replicated?", "slony
I
>> 2.0.3" threads). The usual answer was to stick with the 1.2 branch, but
>> it
>> seemed to me that 2.0.6 got rid of many bugs.
>>
>> So, is it a bug of the 2.0 branch? or is it an expected behaviour? Any
>> tips would be great.
> 
> 
> Are SYNC events being generated on that slave? (examin sl_event on the 
> slave with ev_origin=$slave_id)
> 

Yes, every 10 seconds.

> Are the confirms for those events confirming they have been processed by

> the master making it back to the slave (look at sl_confirm on the slave)
> 

No, the oldest one is around the same time when I stopped the slave.

FYI, I tried 2.1dev, which, to my happy surprise, use the application_name
variable. I have the same behaviour but I noticed that one connection is
not renewed when the slave is up again. It is "slon.node_2_listen" (node 2
is my slave).


-- 
Guillaume
 http://www.postgresql.fr
 http://dalibo.com