Re: Streaming replication on win32, still broken
От | Fujii Masao |
---|---|
Тема | Re: Streaming replication on win32, still broken |
Дата | |
Msg-id | 3f0b79eb1002162155u2f2f81f7w3281c894d8ae2c63@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming replication on win32, still broken (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Streaming replication on win32, still broken
|
Список | pgsql-hackers |
On Wed, Feb 17, 2010 at 6:28 AM, Magnus Hagander <magnus@hagander.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, walreceiverneeds to keep the last half-written WAL block for alignment. OTOH since the received data might end at the middleof 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? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: