Re: Sync Rep v17

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Sync Rep v17
Дата
Msg-id AANLkTini5VhdBCjBs3fBVPa-rNHvgX_qHaP0oA1JgQJE@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sync Rep v17  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Sync Rep v17  (Jaime Casanova <jaime@2ndquadrant.com>)
Re: Sync Rep v17  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Feb 19, 2011 at 3:28 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> First, we should be clear to explain that you are referring to the fact
> that the request
>  synchronous_commit = off
>  synchronous_replication = on
> makes no sense in the way the replication system is currently designed,
> even though it is a wish-list item to make it work in 9.2+

What exactly do you mean by "make it work"?  We can either (1) wait
for the local commit and the remote commit (synchronous_commit=on,
synchronous_replication=on), (2) wait for the local commit only
(synchronous_commit=on, synchronous_replication=off), or (3) wait for
neither (synchronous_commit=off, synchronous_replication=off).
There's no fourth possible behavior, AFAICS.

The question is whether synchronous_commit=off,
synchronous_replication=on should behave like (1) or (3); AFAICS
there's no fourth possible behavior.  You have it as #1; I'm arguing
it should be #3.  I realize it's an arguable point; I'm just arguing
for what makes most sense to me.

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


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: work_mem / maintenance_work_mem maximums
Следующее
От: Tom Lane
Дата:
Сообщение: Re: FDW API: don't like the EXPLAIN mechanism