Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-16 Thread Robert Haas
On Tue, Jun 15, 2010 at 4:22 AM, Fujii Masao masao.fu...@gmail.com wrote: On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 15/06/10 08:23, Fujii Masao wrote: On Thu, Jun 10, 2010 at 11:06 PM, Tom Lanet...@sss.pgh.pa.us  wrote: I'm not sure if

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-15 Thread Fujii Masao
On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 15/06/10 08:23, Fujii Masao wrote: On Thu, Jun 10, 2010 at 11:06 PM, Tom Lanet...@sss.pgh.pa.us  wrote: I'm not sure if it's worth the trouble, or even a particularly smart idea, to force the

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-14 Thread Fujii Masao
On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Even then, we wouldn't need to start from the beginning of the WAL segment AFAICS. The point is to start from the Redo pointer, not from the checkpoint record,

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-14 Thread Heikki Linnakangas
On 15/06/10 08:23, Fujii Masao wrote: On Thu, Jun 10, 2010 at 11:06 PM, Tom Lanet...@sss.pgh.pa.us wrote: I'm not sure if it's worth the trouble, or even a particularly smart idea, to force the output of the status function to be monotonic regardless of what happens underneath. I think

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Fujii Masao
On Thu, Jun 10, 2010 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: I found a term InvalidXLogRecPtr in 9.0 docs.

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Heikki Linnakangas
On 10/06/10 05:56, Tom Lane wrote: Robert Haasrobertmh...@gmail.com writes: On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: I found a term InvalidXLogRecPtr in 9.0 docs.

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Heikki Linnakangas
On 10/06/10 09:42, Fujii Masao wrote: On Thu, Jun 10, 2010 at 11:56 AM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haasrobertmh...@gmail.com writes: On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: I found a term InvalidXLogRecPtr in 9.0 docs.

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Fujii Masao
On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Ah, I just committed a patch to do the same, before seeing your email. Thanks anyway. Yeah, thanks a lot! BTW, the docs claim about pg_last_xlog_location() that While streaming replication is in

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Heikki Linnakangas
On 10/06/10 10:43, Fujii Masao wrote: On Thu, Jun 10, 2010 at 4:07 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: 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

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Fujii Masao
On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: 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

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Heikki Linnakangas
On 10/06/10 11:37, Fujii Masao wrote: On Thu, Jun 10, 2010 at 5:04 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: 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?

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-10 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Even then, we wouldn't need to start from the beginning of the WAL segment AFAICS. The point is to start from the Redo pointer, not from the checkpoint record, because as soon as we read the checkpoint record we'll need to start

[HACKERS] InvalidXLogRecPtr in docs

2010-06-09 Thread Takahiro Itagaki
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

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-09 Thread Robert Haas
On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki itagaki.takah...@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).

Re: [HACKERS] InvalidXLogRecPtr in docs

2010-06-09 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Jun 9, 2010 at 9:46 PM, Takahiro Itagaki itagaki.takah...@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