Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Дата
Msg-id CA+TgmoaHjVVhcHSaq9=G-R9jYE7SurmF7HSoXFxxM019Omj0mQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Tue, May 29, 2012 at 12:47 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Why do you think that doing this for all XLogFlush() callsites might
> be problematic?

Well, consider the one in the background writer, for example.  That's
just a periodic flush, so I see no benefit in having it acquire the
lock and then wait some more.  It already did wait.  And what about
the case where we're flushing while holding WALInsertLock because the
buffer's full?  Clearly waiting is useless in that case - nobody can
join the group commit for exactly the same reason that we're doing the
flush in the first place: no buffer space.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Bogus nestloop rows estimate in 8.4.7
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_basebackup --xlog compatibility break