Yup, restarting the slony processes did help. Odd, that. Thanks!
Chung On 2/8/07, Brad Nicholson <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-07 at 19:58 -0800, Chung Wu wrote: > Hi all, > > I have an odd situation on my hand. I have a simple set up of two > boxes, master and slave, in the obvious way. When I update a tuple in > the master, the change shows up pretty quickly on the slave. > Everything seems to work great! > > Except slony doesn't think so. Instead, slony thinks it's falling > behind: > > blah=# select * from _blah.sl_status; > -[ RECORD 1 ]-------------+--------------------------- > st_origin | 1 > st_received | 2 > st_last_event | 2579833 > st_last_event_ts | 2007-02-07 18:57:35.365256 > st_last_received | 2009491 > st_last_received_ts | 2007-01-12 01:46: 35.341544 > st_last_received_event_ts | 2007-01-12 01:46:35.320719 > st_lag_num_events | 570342 > st_lag_time | 26 days 17:11: 02.395571 > > > blah=# select count(*) from _blah.sl_log_1; > count > --------- > 4177117 > > blah=# select * from _blah.sl_confirm; > con_origin | con_received | con_seqno | con_timestamp > ------------+--------------+-----------+---------------------------- > 2 | 1 | 989608 | 2007-01-12 01:46:34.511849 > 1 | 2 | 2009491 | 2007-01-12 01:46:35.341544 > > > In the master and slave log files, I mostly see happy entries where > cleanupThread was run. However, I do see an error entry on the master > node on 1/12, the fateful day a bit after the slave apparently stopped > sending back confirmations: > > ERROR remoteListenThread_2: timeout for event selection > > Any idea what might be going on? The very large sl_log_1 table is > really slowing us down... The confirmations aren't making it back to the providor. Try restarting your slons and see if the issue goes away. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
