Re: Timeline following for logical slots
От | Alvaro Herrera |
---|---|
Тема | Re: Timeline following for logical slots |
Дата | |
Msg-id | 20160314231058.GA259854@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Timeline following for logical slots (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: Timeline following for logical slots
Re: Timeline following for logical slots Re: Timeline following for logical slots |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: