On Thu, Jan 28, 2010 at 9:32 AM, Erik Rijkers wrote:
> On Wed, January 27, 2010 17:38, Heikki Linnakangas wrote:
>
>> I'll commit it that way.
Thanks Heikki! Yeah, your approach makes more sense.
> This is just to let you know that these commits seem to have solved the bug.
Good! Thanks Erik!
On Wed, January 27, 2010 17:38, Heikki Linnakangas wrote:
> I'll commit it that way.
This is just to let you know that these commits seem to have solved the bug.
I repeated the original test (700 MB pg_restore into a primary,
with two replicating slaves, on one machine).
Checking afterwards:
$
Fujii Masao wrote:
> On Wed, Jan 27, 2010 at 8:37 PM, Heikki Linnakangas
> wrote:
>> But SendRqstPtr comes from LogwrtResult.Write, surely that's correct, no?
>
> Right. But the point is that LogwrtResult.Write might indicate 0/FF00
> because it's the last byte + 1 written out. XLogRead() tre
On Wed, Jan 27, 2010 at 8:37 PM, Heikki Linnakangas
wrote:
> But SendRqstPtr comes from LogwrtResult.Write, surely that's correct, no?
Right. But the point is that LogwrtResult.Write might indicate 0/FF00
because it's the last byte + 1 written out. XLogRead() treats this as the
location where
Fujii Masao wrote:
> On Wed, Jan 27, 2010 at 7:05 PM, Heikki Linnakangas
> wrote:
>> Before that, endptr is advanced using XLByteAdvance() macro, which does
>> handle xlogid boundaries. Is XLByteAdvance() broken?
>
> No. The cause of the bug is that endptr might be set to the SendRqstPtr
> that h
On Wed, Jan 27, 2010 at 7:05 PM, Heikki Linnakangas
wrote:
> Before that, endptr is advanced using XLByteAdvance() macro, which does
> handle xlogid boundaries. Is XLByteAdvance() broken?
No. The cause of the bug is that endptr might be set to the SendRqstPtr
that has crossed a xlogid boundary in
Fujii Masao wrote:
> *** a/src/backend/replication/walsender.c
> --- b/src/backend/replication/walsender.c
> ***
> *** 661,666 XLogSend(StringInfo outMsg)
> --- 661,673
>
> sentPtr = endptr;
>
> + if (sentPtr.xrecoff >= XLogFileSize)
> +
On Wed, Jan 27, 2010 at 4:02 AM, Fujii Masao wrote:
> This is the bug of SR :( I think that walsender wrongly treats the
> WAL-boundary.
The attached patch would fix this bug.
>> pgsql.sr_slave02/logfile:ERROR: could not read xlog records: FATAL: could
>> not open file
>> "pg_xlog/000100
On Wed, Jan 27, 2010 at 2:19 AM, Erik Rijkers wrote:
> Now, when restoring a 700MB dump (made with a 9.0devel pg_dump + pg_restore)
> into the primary,
> errors like the following occur, on all three instances:
>
> FATAL: could not open file "pg_xlog/0001000100FF" (log file 1,
> seg
"Erik Rijkers" wrote:
> FATAL: could not open file "pg_xlog/0001000100FF"
> (log file 1, segment 255): No such file or directory
Yeah, log file segment numbers skip FF; they go from FE to 00 with
the "log file" number (the middle part) bumped by one. Whatever is
coming up with th
I don't know if it has anything to do with HS/SR, I haven't tried it on a
single CVS vanilla
installation (yet).
To test with HS/SR, I've setup three 9.0devel instances (cvs as of today) on a
single machine, one
as a primary, and two as slaves. I used the instructions in
http://wiki.postgres
11 matches
Mail list logo
