Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)

On Thu, Oct 23, 2014 at 2:34 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Thu, Oct 23, 2014 at 9:23 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
> wrote:
> > On Thu, Oct 23, 2014 at 8:45 PM, Heikki Linnakangas
> > <hlinnakangas(at)vmware(dot)com> wrote:
> >> On 10/23/2014 01:25 PM, Michael Paquier wrote:
> >>>
> >>> On Thu, Oct 23, 2014 at 10:09 AM, Heikki Linnakangas <
> >>> hlinnakangas(at)vmware(dot)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?
>

Good catch once again. We could as well put the check of
XLogArchivingActive directly in XLogArchiveNotify...
--
Michael