Re: Should we remove "not fast" promotion at all?

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Should we remove "not fast" promotion at all?
Дата
Msg-id 5203D222.6060505@agliodbs.com
обсуждение исходный текст
Ответ на Should we remove "not fast" promotion at all?  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Should we remove "not fast" promotion at all?  (Andres Freund <andres@2ndquadrant.com>)
Re: Should we remove "not fast" promotion at all?  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Bruce, all:

> We seem to be all over the map with the fast promotion code --- some
> people don't trust it, some people want an option to enable the old
> method, and some people want the old method removed.

Having read over this thread, the only reason given for retaining any
ability to use "old" promotion code is because people are worried about
"fast" promotion being buggy.  This seems wrong.

Either we have confidence is fast promotion, or we don't.  If we don't
have confidence, then either (a) more testing is needed, or (b) it
shouldn't be the default.  Again, here, we are coming up against our
lack of any kind of broad replication failure testing.

Of course, even if we have confidence, bugs are always possible, and
leaving the old promotion code in there would make it somewhat easier to
ship a 9.3.2 update which reverts the behavior.  But maybe we should
focus on shipping a version which is relatively bug-free instead?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Should we remove "not fast" promotion at all?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: mvcc catalo gsnapshots and TopTransactionContext