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? <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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
