Simon Riggs wrote:
>
>
>> What is more, I apparently managed to get the recovery
>> server to lose a WAL file and hang totally by having a bad
>> recovery.conf. Triple ick.
>>
>
> Sounds like a bug you should report in the normal way. Correctness is
> paramount. Or are you confusing the message in the log for file AA with
> an error?
>
No, it had to do with pg_standby waiting for a WAL file that had already
gone, somehow. I will try to reproduce it when I get a spare moment.
>
>> Second, what is all this about .history files? My understanding is that
>> they are not necessary, so surely we should try to stat them to see if
>> they are present before trying to copy them. These lines are going to
>> confuse a lot of people, I suspect (including me).
>>
>
> I try to keep it as simple as possible, since much of this code only
> gets run when you really need it to work. The request for the .history
> file and the cp are examples of that.
>
I don't follow. AFAICT no .history file was in fact archived. ISTM that
in this case we should only call RestoreWALFileForRecovery if the file
in fact exists.
>> Lastly, not quite related to this output, but in the same general area,
>> should we have an option on pg_standby to allow removing the archive
>> file after it has been restored?
>>
>
> There already is one, but its more complex than that. (%r)
>
I was using %r. But the WAL files that have been restored (according to
the log) are still in the archive dir. So it looks like %r isn't working
properly.
> There is an outstanding Windows issue with pg_standby that your help
> would be appreciated with, shown on latest commitfest page. It's a
> Windows issue and I don't maintain a Windows dev environment.
>
>
The patch has been rejected for now, according to the Commitfest page.
Not sure what you want my help on.
BTW, none of what I reported was on Windows - it's on Linux.
cheers
andrew