On Sun, Sep 4, 2016 at 11:30 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 4 September 2016 at 14:32, Abhijit Menon-Sen <a...@2ndquadrant.com> wrote:
>> At 2016-09-04 07:02:01 +0100, si...@2ndquadrant.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?

+   <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".

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

Reply via email to