Re: LSN as a recovery target

On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 4 September 2016 at 14:32, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
>> At 2016-09-04 07:02:01 +0100, simon(at)2ndquadrant(dot)com wrote:
>>>
>>> > By the way, what has been committed does not include the patch
>>> > adding the parsing context in case of an error as wanted upthread.
>>> > Perhaps that's not worth adding now as there is the GUC refactoring
>>> > potentially happening for the recovery parameters, so I don't mind
>>> > much. Just that's worth mentioning.
>>>
>>> Hmm, that was unintentional. If something stalls the recovery
>>> parameter project, please remind me to commit that as well.
>>
>> I'm aware of this, and will adjust accordingly in the GUC patch. Thanks
>> for the heads up.
>
> I noticed we don't mention what LSN is anywhere, so I'd like to apply
> the following doc patch also.

+1 for the idea. What do you think about adding a mention to the
system data type pg_lsn?

<para>
+ <acronym>WAL</acronym> records are appended to the <acronym>WAL</acronym>
+ logs as each new record is written. The insert position is described by
+ a Log Sequence Number (<acronym>LSN</acronym>) that is a byte offset into
+ the logs, increasing monotonically with each new record. Two
+ <acronym>LSN</acronym>s can be compared to calculate the volume of
+ <acronym>WAL</acronym> data that separates them, so are used to measure
+ progress of <acronym>WAL</acronym> during replication and recovery.
+ </para>
Here we could for example append a sentence like "The system data type
<link linkend="datatype-pg-lsn"><type>pg_lsn</></link> is an internal
representation of the LSN".
--
Michael