Re: LSN as a recovery target

From: Adrien Nayrat <adrien(dot)nayrat(at)dalibo(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Christoph Berg <myon(at)debian(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>
Subject: Re: LSN as a recovery target
Date: 2016-08-19 13:47:56
Message-ID: ca54db66-2284-f0eb-a916-aa2479edf6d8@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/09/2016 02:33 PM, Michael Paquier wrote:
> On Wed, May 25, 2016 at 1:32 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)com> wrote:
>>> Christoph Berg wrote:
>>>> Re: Michael Paquier 2016-05-24 <CAB7nPqQRXsC8=ozh6GpjLnpZ=MeooUZOaAbzx28n2bjSMv2B4g(at)mail(dot)gmail(dot)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.
>
>
>
>

Hi,

I reviewed this patch rebased to deal with
f6ced51f9188ad5806219471a0b40a91dde923aa, and minor adjustment (see below)

It do the job. However if you use an incorrect recovery_target_lsn you
get this message :
"FATAL: invalid input syntax for type pg_lsn: "0RT5/4""

I added a PG_TRY/PG_CATCH section in order to get a more explicit message :
FATAL: wrong recovery_target_lsn (must be pg_lsn type)

I am not sure if it is the best solution?

Thanks to Julien Rouhaud for his help.

--
Adrien NAYRAT

http://dalibo.com - http://dalibo.org

Attachment Content-Type Size
recovery-target-lsn-2.patch text/x-patch 10.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-08-19 14:00:15 Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location
Previous Message Yury Zhuravlev 2016-08-19 13:46:38 Re: WIP: About CMake v2