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

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: [HACKERS] Quorum commit for multiple synchronous replication.
Дата
Msg-id CAD21AoAVdGzqev1n2E1-Fcc-MDwpNczpeZmaNbeQpgNs-o6_Tg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Quorum commit for multiple synchronous replication.  (Noah Misch <noah@leadboat.com>)
Ответы Re: [HACKERS] Quorum commit for multiple synchronous replication.
Re: [HACKERS] Quorum commit for multiple synchronous replication.
Список pgsql-hackers
On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch <noah@leadboat.com> wrote:
> On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote:
>> On Sun, Apr 16, 2017 at 1:19 PM, Noah Misch <noah@leadboat.com> wrote:
>> > On Fri, Apr 14, 2017 at 11:58:23PM -0400, Noah Misch wrote:
>> >> On Wed, Apr 05, 2017 at 09:51:02PM -0400, Noah Misch wrote:
>> >> > On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>> >>
>> >> > > > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>> >> > > >> (3)
>> >> > > >> The priority value is assigned to each standby listed in s_s_names
>> >> > > >> even in quorum commit though those priority values are not used at all.
>> >> > > >> Users can see those priority values in pg_stat_replication.
>> >> > > >> Isn't this confusing? If yes, it might be better to always assign 1 as
>> >> > > >> the priority, for example.
>
>> >> This PostgreSQL 10 open item is past due for your status update.  Kindly send
>> >> a status update within 24 hours, and include a date for your subsequent status
>> >> update.  Refer to the policy on open item ownership:
>> >> https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
>
>> >> > Since you do want (3) to change, please own it like any other open item,
>> >> > including the mandatory status updates.
>> >>
>> >> Likewise.
>>
>> As I told firstly this is not a bug. There are some proposals for better design
>> of priority column in pg_stat_replication, but we've not reached the consensus
>> yet. So I think that it's better to move this open item to "Design Decisions to
>> Recheck Mid-Beta" section so that we can hear more opinions.
>
> I'm reading that some people want to report NULL priority, some people want to
> report a constant 1 priority, and nobody wants the current behavior.  Is that
> an accurate summary?

Yes, I think that's correct.

FWIW the reason of current behavior is that it would be useful for the
user who is willing to switch from ANY to FIRST. They can know which
standbys will become sync or potential.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Следующее
От: Pavan Deolasee
Дата:
Сообщение: [HACKERS] Assertion failure in REL9_5_STABLE