On Sat, Aug 20, 2016 at 10:44 AM, Petr Jelinek <p...@2ndquadrant.com> wrote:
> On 20/08/16 02:13, Michael Paquier wrote:
>> On Fri, Aug 19, 2016 at 10:47 PM, Adrien Nayrat
>> <adrien.nay...@dalibo.com> wrote:
>> Using a PG_TRY/CATCH block the way you do to show to user a different
>> error message while the original one is actually correct does not
>> sound like a good idea to me. It complicates the code and the original
>> pattern matches what is already done for timestamps, where in case of
>> error you'd get that:
>> FATAL:  invalid input syntax for type timestamp with time zone: "aa"
>> I think that a better solution would be to make clearer in the docs
>> that pg_lsn is used here. First, in recovery.conf.sample, let's use
>> pg_lsn and not LSN. Then, in the sgml docs, let's add a reference to
>> the page of pg_lsn as well:
>> https://www.postgresql.org/docs/devel/static/datatype-pg-lsn.html
>> Now we have that:
>> +       <para>
>> +        This parameter specifies the LSN of the write-ahead log stream up
>> to
>> +        which recovery will proceed. The precise stopping point is also
>> +        influenced by <xref linkend="recovery-target-inclusive">.
>> +       </para>
>> Perhaps we could just add an additional sentence: "This parameter
>> value is parsed using the system datatype <link=pg_lsn>". Or something
>> like that. Thoughts?
> +1

So here is the patch resulting in that. After thinking more about that
I have arrived at the conclusion to not use LSN in recovery.conf, but
"WAL position (LSN)", and also mention in the docs that pg_lsn is used
to parse the parameter value. A couple of log messages are changed
similarly. It definitely makes it more understandable for users to
speak of WAL positions.

I also noticed that the top block of "Recovery Target Settings" needs
to mention recovery_target_lsn, aka when name, xid, lsn and time are
combined in the same recovery.conf, only the last value will be used.

Attachment: recovery-target-lsn-3.patch
Description: application/download

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to