Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Дата
Msg-id AANLkTinymDD4joLtEEy8EGzNmVF=j=Ma6_n3K+6ohKTx@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Wed, Mar 23, 2011 at 3:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> In any case, that's not the only argument for keeping it. We introduce
> the view in this release and I would like it to stay the same from
> now, since we know we will need that info later.

At least as I understand it, it's not our project policy to carry
around code that doesn't accomplish anything useful.  I have no
objection to keeping the field; I simply think that if we're going to
have it, we should make it work, as in fact it did before you changed
it without discussion.  You haven't offered any evidence at all that
it introduces any kind of a performance regression AT ALL, much less
that such any such regression can't be trivially patched around by
making SyncRepReleaseWaiters exit quickly if the flush LSN hasn't
advanced.  The onus is as much on you to justify the change as it is
on me to justify changing it back.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: 2nd Level Buffer Cache
Следующее
От: Robert Haas
Дата:
Сообщение: Re: psql \dt and table size