Re: Parallelize stream replication process

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Li Japin <japinli(at)hotmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallelize stream replication process
Date: 2020-09-15 07:41:33
Message-ID: 7f493ebf-ba89-37ee-6103-a4ccb865e3ad@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/09/15 13:41, Bharath Rupireddy wrote:
> On Tue, Sep 15, 2020 at 9:27 AM Li Japin <japinli(at)hotmail(dot)com> wrote:
>>
>> For now, postgres use single process to send, receive and replay the WAL when we use stream replication,
>> is there any point to parallelize this process? If it does, how do we start?
>>
>> Any thoughts?

Probably this is another parallelism than what you're thinking,
but I was thinking to start up walwriter process in the standby server
and make it fsync the streamed WAL data. This means that we leave
a part of tasks of walreceiver process to walwriter. Walreceiver
performs WAL receive and write, and walwriter performs WAL flush,
in parallel. I'm just expecting that this change would improve
the replication performance, e.g., reduce the time to wait for
sync replication.

Without this change (i.e., originally), only walreceiver performs
WAL receive, write and flush. So wihle walreceiver is fsyncing WAL data,
it cannot receive newly-arrived WAL data. If WAL flush takes a time,
which means that the time to wait for sync replication in the primary
would be enlarged.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-09-15 08:10:34 Re: New statistics for tuning WAL buffer size
Previous Message Amit Langote 2020-09-15 07:39:43 Re: pg_restore causing deadlocks on partitioned tables