On Wed, May 25, 2016 at 1:32 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> Christoph Berg wrote:
>>> Re: Michael Paquier 2016-05-24 <CAB7nPqQRXsC8=ozh6GpjLnpZ=MeooUZOaAbzx28n2bjSMv2B4g@mail.gmail.com>
>>> > Yeah, that's really something that covers only a narrow case, though
>>> > if we don't have it when we need it we're limited to some hacks.
>>> > Perhaps people who have the advanced level to use such a thing have
>>> > the level to use hacks anyway..
>>>
>>> I'd think recovery_target_lsn would be more useful in practice than
>>> the existing recovery_target_xid. So I don't see why it shouldn't just
>>> be added, also given it's likely very unobtrusive to do so.
>>
>> Also, see
>> http://www.postgresql.org/message-id/56BD0E4E.5050503@2ndquadrant.com
>
> Looking at xlog.c it is not that complicated, and we could add tests
> in 003_recovery_targets.pl at the same time. Perhaps somebody looking
> for a first participation would be interested in this small project?
Oh, well. I have implemented it as attached by introducing
recovery_target_lsn as a new recovery parameter. This takes into
account recovery_target_inclusive and stops at the precise point of a
record without being influenced by the xact records, in a way similar
recovery_target_name. Tests and documentation are added, and this is
part of the next CF.
--
Michael