Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves) - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Date
Msg-id CAHGQGwG96x6YGf5jOA63sAanGnNkkrCv9MWZweCMfRfW8H90TA@mail.gmail.com
Whole thread Raw
In response to Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
List pgsql-hackers
On Thu, Oct 23, 2014 at 9:23 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Oct 23, 2014 at 8:45 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> On 10/23/2014 01:25 PM, Michael Paquier wrote:
>>>
>>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
>>> hlinnakangas@vmware.com> wrote:
>>>
>>>> On 10/23/2014 08:59 AM, Fujii Masao wrote:
>>>> Sounds reasonable, for back-branches. Although I'm still worried we might
>>>> miss some corner-case unless we go with a more wholesale solution.
>>>>
>>>
>>> Don't really want to be the intruder here, but isn't that the simple patch
>>> attached?
>>
>>
>> That's not right. Should check *after* the write if the segment was
>> completed, and close it if so. Like the attached.
>
> Looks good to me. WalReceiverMain has almost the same code as
> what XLogWalRcvFileClose does. So we can refactor that.

While looking at the code of WAL archiving and recovery, I found
another small issue. The standby always creates .ready file for
the timeline history file even when WAL archiving is not enabled.
Since WAL archiving is off, that .ready file will remain infinitely.
Probably this is almost harmless but confusing, so I'd like to fix that.
Patch attached. Thought?

Regards,

--
Fujii Masao

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Next
From: Craig Ringer
Date:
Subject: Re: [Windows,PATCH] Use faster, higher precision timer API