|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Petr Jelinek <petr(at)2ndquadrant(dot)com>|
|Cc:||Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Re: Timeline following for logical slots|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Petr Jelinek wrote:
> On 04/03/16 17:08, Craig Ringer wrote:
> >I'd really appreciate some review of the logic there by people who know
> >timelines well and preferably know the xlogreader. It's really just one
> >function and 2/3 comments; the code is simple but the reasoning leading
> >to it is not.
> I think this will have to be work for committer at this point. I can't find
> any flaws in the logic myself so I unless somebody protests I am going to
> mark this as ready for committer.
Great, thanks. I've studied this to the point where I'm confident that
it makes sense, so I'm about to push it. I didn't change any logic,
only updated comments here and there, both in the patch and in some
preexisting code. I also changed the "List *timelineHistory" to be
#ifndef FRONTEND, which seems cleaner than having it and insist that it
couldn't be used.
Also, hopefully you don't have any future callers for the functions I
marked static (I checked the failover slots series and couldn't see
anything). I will push this early tomorrow.
One thing I'm not quite sure about is why this is said to apply to
"logical slots" and not just to replication slots in general. In what
sense does it not apply to physical replication slots?
(I noticed that we have this new line,
- randAccess = true;
+ randAccess = true; /* allow readPageTLI to go backwards */
in which now the comment is an identical copy of an identical line
elsewhere; however, randAccess doesn't actually affect readPageTLI in
any way, so AFAICS both comments are now wrong.)
> Well for testing purposes it's quite fine I think. The TAP framework
> enhancements needed for this are now in and it works correctly against
> current master.
Certainly the new src/test/recovery/t/006whatever.pl file is going to be
part of the commit. What I'm not so sure about is
src/test/modules/decoding_failover: is there any reason we don't just
put the new functions in contrib/test_decoding?
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Robbie Harwood||2016-03-14 23:11:42||[PATCH v7] GSSAPI encryption support|
|Previous Message||Michael Paquier||2016-03-14 23:07:53||Re: Password identifiers, protocol aging and SCRAM protocol|