Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly
Дата
Msg-id CA+TgmoYJQaJXr4A+4huztZOj7_ZFyAgYOxVNOp4rtckc4RtVvQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly
Список pgsql-hackers
On Thu, Nov 10, 2016 at 12:13 AM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
>> OK.  I agree that's a problem.  However, your patch adds zero new comment
>> text while removing some existing comments, so I can't easily tell how it
>> solves that problem or whether it does so correctly.  Even if I were smart
>> enough to figure it out, I wouldn't want to rely on the next person also
>> being that smart.  This is obviously a subtle problem in tricky code, so
>> a clear explanation of the fix seems like a very good idea.
>
> The comment describes what the code is trying to achieve.  Actually, I just imitated the code and comment of later
majorreleases.  The only difference between later releases and my patch (for 9.2) is whether the state is stored in
XLogReaderStructor as global variables.  Below is the comment from 9.6, where the second paragraph describes what the
twonested if conditions mean.  The removed comment lines are what became irrelevant, which is also not present in later
majorreleases. 

Let me try to be more clear.  I will not commit this patch if it is
not properly commented.  I doubt that anyone else will, either.

The fact that those code changes already exist in 9.4+ is not a reason
to back-port them to earlier releases without a proper explanation of
why we are doing it.  Very possibly, we should also improve the
comments in newer branches so that future authors don't reintroduce
whatever bugs were fixed by these changes.  But whether we do that or
not, I am not going to commit uncommented patches to complex code in
order to fix obscure bugs in 3+-year-old branches.  I think that is a
non-starter.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Something is broken about connection startup
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Pinning a buffer in TupleTableSlot is unnecessary