On 2 May 2013 08:31, Magnus Hagander <magnus@hagander.net> wrote:
> That said, there is one property that's very unclear now and that's
> that you can only set one of recovery_target_time, recovery_target_xid
> and recovery_target_name. But they can be freely combined with
> recovery_target_timeline and recovery_target_inclusive. That's quite
> confusing.
In the docs we say "At most one of recovery_target_time,
recovery_target_name or recovery_target_xid can be specified." on each
of those parameter descriptions.
In recovery.conf.sample, we say
# You may set a recovery target either by transactionId, by name,
# or by timestamp. Recovery may either include or exclude the
# transaction(s) with the recovery target value (ie, stop either
# just after or just before the given target, respectively).
Who is confused by that? And if they are, why would they be less
confused with changed *syntax*? I think most people just copy the
examples anyway, they don't care about the syntax.
As we just saw, changing the syntax may introduce other consistency
issues and confusions that weren't there before. If the precise syntax
is the essence of a new and improved interface, surely it needs to be
fully worked out before anybody agrees.
It has always been the case that recovery is a complex topic and one
that is used in stressful circumstances. It isn't the syntax that
makes using this hard, its the fact that the process itself is
non-trivial and not easy to use without some prior thought and testing
of how recovery will work for a particular company/enterprise.
I'm very progressive about both new features and usability
improvements, but rearranging things for minor reasons just feels like
a waste.
If we feel strongly about user interface design problems we should
treat them the same way we treat performance issues. Profile to
identify problem areas, analyze problems in those areas and suggest
solutions, then make tests to check that the new interface genuinely
works better than the old. That is proper UI improvement, not just
knee jerk reactions.
--Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
