On Wed, May 25, 2016 at 1:32 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: >> Christoph Berg wrote: >>> Re: Michael Paquier 2016-05-24 >>> <CAB7nPqQRXsC8=ozh6GpjLnpZ=meoouzoaabzx28n2bjsmv2...@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.5050...@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
recovery-target-lsn.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
