Re: Change pg_last_xlog_receive_location not to move backwards
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Fujii Masao <masao.fujii@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-11T17:25:29Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Typo fixes. receivedUpto should be capitalized consistently.
- d309acf201ab 9.1.0 cited
On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost <sfrost@snowman.net> wrote: > Fujii, all, > > * Fujii Masao (masao.fujii@gmail.com) wrote: >> That logic exists because we'd like to check that newly-received WAL >> data is consistent with previous one by validating the header of new >> WAL file. So since we need the header of new WAL file, we retreat the >> replication starting location to the beginning of the WAL file when >> reconnecting to the primary. > > Thanks for that explanation, but I can't help but wonder why it doesn't > make more sense to introduce a new variable to track the value you want > rather than reusing an existing one and then adding a variable to > represent what the old variable was already doing. +1. It seems like there may be some more significant changes in this area needed; however, for now I think the best fix is the one with the least chance of breaking anything. > Also, you really should reformat the docs properly when you change them, > rather than leaving the lines ragged.. It's OK to leave them a little ragged, I think. It eases back-patching. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company