From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Use durable_unlink for .ready and .done files for WAL segment removal |
Date: | 2018-09-28 23:11:43 |
Message-ID: | 20180928231143.GC1823@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 28, 2018 at 02:36:19PM -0400, Stephen Frost wrote:
> Is there an issue with making the archiver able to understand that
> situation instead of being confused by it..? Seems like that'd probably
> be a good thing to do regardless of this, but that would then remove the
> need for this kind of change..
I thought about that a bit, and there is as well a lot which can be done
within the archive_command itself regarding that, so I am not sure that
there is the argument to make pgarch.c more complicated than it should.
Now it is true that for most users having a .ready file but no segment
would most likely lead in a failure. I suspect that a large user base
is still just using plain cp in archive_command, which would cause the
archiver to be stuck. So we could actually just tweak pgarch_readyXlog
to check if the segment fetched actually exists (see bottom of the
so-said function). If it doesn't, then the archiver removes the .ready
file and retries fetching a new segment.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-09-28 23:12:11 | Re: [PATCH] Include application_name in "connection authorized" log message |
Previous Message | Andres Freund | 2018-09-28 22:41:27 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |