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

Re: Streaming replication on win32, still broken

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication on win32, still broken
Date: 2010-02-17 05:55:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 17, 2010 at 6:28 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> If you send me your amazon id, I can get you premissions on my private
> image. I plan to clean it up and make it public, just haven't gotten
> around to it yet...

Thanks for your concern! I'll send the ID when I complete the preparation.

And, fortunately?, when I set wal_sync_method to open_sync, the problem was
reproduced in the linux, too. The cause is that the data that is written by
walreceiver is not aligned, even if O_DIRECT is used. On win32, O_DIRECT is
used by default. So the problem always happened on win32.

I propose two solution ideas:

1. O_DIRECT is somewhat harmful in the standby since the data written by
   walreceiver is read by the startup process immediately. So, how about
   not making only walreceiver use O_DIRECT?

2. Straightforwardly observe the alignment rule. Since the received WAL
   data might start at the middle of WAL block, walreceiver needs to keep
   the last half-written WAL block for alignment. OTOH since the received
   data might end at the middle of WAL block, walreceiver needs zero-padding.
   As a result, walreceiver writes the set of the last WAL block, received
   data and zero-padding.

Which is better? Or do you have another better idea?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-02-17 06:03:44
Subject: Re: Streaming replication on win32, still broken
Previous:From: Andrew DunstanDate: 2010-02-17 05:35:16
Subject: Re: [COMMITTERS] pgsql: Clean up package namespace use and use of Safe in plperl.

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