Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication on win32, still broken

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication on win32, still broken
Date: 2010-02-16 10:20:31
Message-ID: 9837222c1002160220l2ccec5aaqfccb55748c1c4892@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/2/16 Fujii Masao <masao(dot)fujii(at)gmail(dot)com>:
> On Tue, Feb 16, 2010 at 12:37 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> With the libpq fixes, I get further (more on that fix later, btw), but
>> now I get stuck in this. When I do something on the master that
>> generates WAL, such as insert a record, and then try to query this on
>> the slave, the walreceiver process crashes with:
>>
>> PANIC:  XX000: could not write to log file 0, segment 9 at offset 0, length 160:
>>  Invalid argument
>> LOCATION:  XLogWalRcvWrite, .\src\backend\replication\walreceiver.c:487
>>
>> I'll keep digging at the details, but if somebody has a good idea here.. ;)
>
> Yeah, this problem was reproduced in my (very slow :-( ) MinGW environment, too.
> Though I've not idenfied the cause yet, I guess that it derives from wrong use
> of the type of local variables in XLogWalRcvWrite(). I'll continue investigation
> of it.

Thanks!

I will be somewhat spottily available over the next two days due to
on-site work with clients.

Let me know if you would be helped by some details of how to get a
(somewhat faster) EC2 image up and running with MSVC to test on :-)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-02-16 10:36:50
Subject: Re: Explain buffers display units.
Previous:From: Fujii MasaoDate: 2010-02-16 09:56:16
Subject: Re: Streaming replication on win32, still broken

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group