Re: WALWriter active during recovery

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WALWriter active during recovery
Date: 2015-03-05 08:22:28
Message-ID: CAHGQGwFfbzdNrNzQdpH8N3yHSd1XCpd7ybxQ0q0yOwk2v=se8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 18, 2014 at 6:43 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Currently, WALReceiver writes and fsyncs data it receives. Clearly,
>> while we are waiting for an fsync we aren't doing any other useful
>> work.
>>
>> Following patch starts WALWriter during recovery and makes it
>> responsible for fsyncing data, allowing WALReceiver to progress other
>> useful actions.

With the patch, replication didn't work fine in my machine. I started
the standby server after removing all the WAL files from the standby.
ISTM that the patch doesn't handle that case. That is, in that case,
the standby tries to start up walreceiver and replication to retrieve
the REDO-starting checkpoint record *before* starting up walwriter
(IOW, before reaching the consistent point). Then since walreceiver works
without walwriter, no received WAL data cannot be fsync'd in the standby.
So replication cannot advance furthermore. I think that walwriter needs
to start before walreceiver starts.

I just marked this patch as Waiting on Author.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-03-05 08:25:42 Re: Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary
Previous Message Amit Kapila 2015-03-05 08:21:16 Re: TABLESAMPLE patch