InvalidXLogRecPtr in docs
in [PgSql]
|
From: Robert Haas on 9 Jun 2010 21:54 On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> wrote: > I found a term "InvalidXLogRecPtr" in 9.0 docs. > http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE > | ... then the return value will be InvalidXLogRecPtr (0/0). > > I think it should not appear in docs because it's a name for an internal > constant variable. I'd like to rewrite the description like: > > ... then the return value will be 0/0, that is never used in normal cases. > > Comments? Maybe we should be returning NULL instead of 0/0. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 9 Jun 2010 22:56 Robert Haas <robertmhaas(a)gmail.com> writes: > On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki > <itagaki.takahiro(a)oss.ntt.co.jp> wrote: >> I found a term "InvalidXLogRecPtr" in 9.0 docs. >> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE >> | ... then the return value will be InvalidXLogRecPtr (0/0). > Maybe we should be returning NULL instead of 0/0. +1 for using NULL instead of an artificially chosen value, for both of those functions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 10 Jun 2010 02:42 On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki >> <itagaki.takahiro(a)oss.ntt.co.jp> wrote: >>> I found a term "InvalidXLogRecPtr" in 9.0 docs. >>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE >>> | ... then the return value will be InvalidXLogRecPtr (0/0). > >> Maybe we should be returning NULL instead of 0/0. > > +1 for using NULL instead of an artificially chosen value, for both of > those functions. Okay, the attached patch makes those functions return NULL in that case. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
From: Heikki Linnakangas on 10 Jun 2010 03:00 On 10/06/10 05:56, Tom Lane wrote: > Robert Haas<robertmhaas(a)gmail.com> writes: >> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki >> <itagaki.takahiro(a)oss.ntt.co.jp> wrote: >>> I found a term "InvalidXLogRecPtr" in 9.0 docs. >>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE >>> | ... then the return value will be InvalidXLogRecPtr (0/0). > >> Maybe we should be returning NULL instead of 0/0. > > +1 for using NULL instead of an artificially chosen value, for both of > those functions. Agreed, committed a patch to do that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 10 Jun 2010 03:07 On 10/06/10 09:42, Fujii Masao wrote: > On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas<robertmhaas(a)gmail.com> writes: >>> On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki >>> <itagaki.takahiro(a)oss.ntt.co.jp> wrote: >>>> I found a term "InvalidXLogRecPtr" in 9.0 docs. >>>> http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-RECOVERY-INFO-TABLE >>>> | ... then the return value will be InvalidXLogRecPtr (0/0). >> >>> Maybe we should be returning NULL instead of 0/0. >> >> +1 for using NULL instead of an artificially chosen value, for both of >> those functions. > > Okay, the attached patch makes those functions return NULL in that case. Ah, I just committed a patch to do the same, before seeing your email. Thanks anyway. BTW, the docs claim about pg_last_xlog_location() that "While streaming replication is in progress this will increase monotonically." That's a bit misleading: when the replication connection is broken for some reason and we restart it, we begin streaming from the beginning of the last WAL segment. So at that moment, pg_last_xlog_location() moves backwards to the beginning of the WAL segment. Should we: 1. Just document that, 2. Change pg_last_xlog_location() to not move backwards in that case, or 3. Change the behavior so that we start streaming at the exact byte location where we left off? I believe that starting from the beginning of the WAL segment is just paranoia, to avoid creating a WAL file that's missing some data from the beginning. Right? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] InvalidXLogRecPtr in docs Next: [HACKERS] fix use of posix_fadvise in xlog.c |