Fri Oct 20 15:04:40 PDT 2006
- Previous message: [Slony1-general] Location of Win32 pre-built binaries
- Next message: [Slony1-general] Master CPU with more than 30%
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Oct 20, 2006 at 02:36:48PM -0600, paul cannon wrote: > On Wed, Oct 18, 2006 at 10:12:54PM +0000, Christopher Browne wrote: > > We've discovered Another Problem that warrants holding on a little bit > > for 1.2.1. > > > > <http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1591> > > > > It seems that this line explains the problem: "ERROR > > remoteHelperThread_1_1: large log_cmddata for actionseq fetch 100 from > > LOG; not found" > > > > The problem is that the "large object search" code only consults > > sl_log_1 to look for "large tuples". > > > > Where it occurs is fairly well identified; it will take a couple days to > > get the fix working and tested :-(. > > So say we've already found ourselves in this situation. Is there > anything that can be done to get slony un-wedged? We don't even have any > large objects. I guess they were large enough. Turning up sync_max_rowsize to its maximum still wasn't enough to skip the special large object optimization handling. I came up with a lame solution, the patch for which I'll attach to the bug referenced above. I'm sure you slony people can come up with something a lot more efficient and whatnot, but this at least lets my replication work again. -- paul
- Previous message: [Slony1-general] Location of Win32 pre-built binaries
- Next message: [Slony1-general] Master CPU with more than 30%
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list