Re: [HACKERS] Quorum commit for multiple synchronous replication.

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Quorum commit for multiple synchronous replication.
Дата
Msg-id CAB7nPqTbXbwRAA_Up-22Of+bSHzXCjjwsSCoEbkcmcXVLvxx3Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Thu, Dec 15, 2016 at 11:04 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Thu, Dec 15, 2016 at 6:47 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Dec 14, 2016 at 11:34 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> If we drop the "standby_list" syntax, I don't think that new parameter is
>>> necessary. We can keep s_s_names and just drop the support for that syntax
>>> from s_s_names. This may be ok if we're really in "break all the things" mode
>>> for PostgreSQL 10.
>>
>> Please let's not raise that as an argument again... And not break the
>> s_list argument. Many users depend on that for just single sync
>> standbys. FWIW, I'd be in favor of backward compatibility and say that
>> a standby list is a priority list if we can maintain that. Upthread
>> agreement was to break that, I did not insist further, and won't if
>> that's still the feeling.
>
> I wonder why you think that the backward-compatibility for standby_list is
> so "special". We renamed pg_xlog directory to pg_wal and are planning to
> change recovery.conf API at all, though they have bigger impacts on
> the existing users in terms of the backward compatibility. OTOH, so far,
> changing GUC between major releases happened several times.

Silent failures for existing failover deployments is a pain to solve
after doing upgrades. That's my only concern. Changing pg_wal would
result in a hard failure when upgrading. And changing the meaning of
the standby list (without keyword ANY or FIRST!) does not fall into
that category... So yes just removing support for standby list would
result in a hard failure, which would be fine for the
let-s-break-all-things move.

> But I'm not against keeping the backward compatibility for standby_list,
> to be honest. My concern is that the latest patch tries to support
> the backward compatibility "partially" and which would be confusing to users,
> as I told upthread.

If we try to support backward compatibility, I'd personally do it
fully, and have a list of standby names specified meaning a priority
list.

> So I'd like to propose to keep the backward compatibility fully for s_s_names
> (i.e., both "standby_list" and "N (standby_list)" mean the priority method)
> at the first commit, then continue discussing this and change it if we reach
> the consensus until PostgreSQL 10 is actually released. Thought?

+1 on that.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)