On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin <g.smol...@postgrespro.ru>
wrote in
On 11/6/19 1:55 PM, Grigory Smolkin wrote:
On 11/6/19 12:56 PM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin
<g.smol...@postgrespro.ru> wrote:
On 11/6/19 10:39 AM, Peter Eisentraut wrote:
This seems to also be related to this discussion:
<https://www.postgresql.org/message-id/flat/993736dd3f1713ec1f63fc3b65383...@lako.no>
Yes, in a way. Strengthening current lax recovery behavior is a very
good idea.
I like this idea.
I don't like the name "latest". What does that mean? Other
documentation talks about the "end of the archive". What does that
mean? It means until restore_command errors. Let's think of a name
that reflects that better. Maybe "all_archive" or something like
that.
As with "immediate", "latest" reflects the latest possible state this
PostgreSQL instance can achieve when using PITR. I think it is simple
and easy to understand for an end user, which sees PITR as a way to go
from one state to another. In my experience, at least, which is, of
course, subjective.
But if we want an argument name to be technically accurate, then, I
think, something like "end-of-available-WAL"/"all-WAL", "end-of-WAL"
is
a way to go.
What happens if this parameter is set to latest in the standby mode?
Or the combination of those settings should be prohibited?
Currently it will behave just like regular standby, so I think, to
avoid confusion and keep things simple, the combination of them should
be prohibited.
Thank you for pointing this out, I will work on it.
Attached new patch revision, now it is impossible to use
recovery_target 'latest' in standby mode.
TAP test is updated to reflect this behavior.
In the first place, latest (or anything it could be named as) is
defined as the explit label for the default behavior. Thus the latest
should work as if nothing is set to recovery_target* following the
definition. That might seems somewhat strange but I think at least it
is harmless.
Well, it was more about getting default behavior by using some explicit
recovery_target, not the other way around. Because it will break some
3rd party backup and replication applications, that may rely on old
behavior of ignoring recovery_target_action when no recovery_target is
provided.
But you think that it is worth pursuing, I can do that.
recovery_target=immediate + r_t_action=shutdown for a standby works as
commanded. Do we need to inhibit that, too?
Why something, that work as expected, should be inhibited?
The other way around, as I see it, is to define RECOVERY_TARGET_LATEST
as something more complex, for example, the latest possible endptr in
latest WAL segment. But it is tricky, because WAL archive may keeps
growing as recovery is progressing or, in case of standby, master
keeps sending more and more WAL.
regards.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
