From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Subject: | Re: Synchronous replication |
Date: | 2010-07-27 05:28:29 |
Message-ID: | AANLkTimfxY2QJPbrkoobrMLvGP8tGmT-_7ObPKbbWaPC@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 21, 2010 at 4:36 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> I was actually hoping to see a patch for these things first, before any of
>> the synchronous replication stuff. Eliminating the polling loops is
>> important, latency will be laughable otherwise, and it will help the
>> synchronous case too.
>
> At first, note that the poll loop in the backend and walreceiver doesn't
> exist without synchronous replication stuff.
>
> Yeah, I'll start with the change of the poll loop in the walsender. I'm
> thinking that we should make the backend signal the walsender to send the
> outstanding WAL immediately as the previous synchronous replication patch
> I submitted in the past year did. I use the signal here because walsender
> needs to wait for the request from the backend and the ack message from
> the standby *concurrently* in synchronous replication. If we use the
> semaphore instead of the signal, the walsender would not be able to
> respond the ack immediately, which also degrades the performance.
>
> The problem of this idea is that signal can be sent per transaction commit.
> I'm not sure if this frequent signaling really harms the performance of
> replication. BTW, when I benchmarked the previous synchronous replication
> patch based on the idea, AFAIR the result showed no impact of the
> signaling. But... Thought? Do you have another better idea?
The attached patch changes the backend so that it signals walsender to
wake up from the sleep and send WAL immediately. It doesn't include any
other synchronous replication stuff.
The signal is sent right after a COMMIT, PREPARE TRANSACTION,
COMMIT PREPARED or ABORT PREPARED record has been fsync'd.
To suppress redundant signaling, I added the flag which indicates whether
walsender is ready for sending WAL up to the currently-fsync'd location.
Only when the flag is false, the backend sets it to true and sends the
signal to walsender. When the flag is true, the signal doesn't need to be
sent. The flag is set to false right before walsender sends WAL.
The code is also available in my git repository:
git://git.postgresql.org/git/users/fujii/postgres.git
branch: wakeup-walsnd
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
change_poll_loop_in_walsender_0727.patch | application/octet-stream | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-07-27 06:22:54 | Re: patch (for 9.1) string functions |
Previous Message | Boxuan Zhai | 2010-07-27 05:04:05 | merge command - GSoC progress |