Re: WAL Rate Limiting

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: WAL Rate Limiting
Дата
Msg-id CA+Tgmobdk+i=cJBBW_UH3ysEKPYT1OuzLEAWmHB0Lo=1tBxHUg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: WAL Rate Limiting  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Jan 16, 2014 at 10:56 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> That'd be most places doing XLogInsert() if you want to be
> consistent. Each needing to be analyzed whether we're blocking important
> resources, determining where in the callstack we can do the
> CHECK_FOR_WAL_BUDGET().

And doing that probably wouldn't be a problem except for the fact that
this patch is showing up at the absolute very last minute with
multiple unresolved design considerations.  I'm with Tom: this should
be postponed to 9.5.

That having been said, I bet it could be done at the tail of
XLogInsert().  if there are cases where that's not desirable, then add
macros HOLDOFF_WAL_THROTTLING() and RESUME_WAL_THROTTLING() that bump
a counter up and down.  When the counter is >0, XLogInsert() doesn't
sleep; when RESUME_WAL_THROTTLING() drops the counter to 0, it also
considers sleeping.  I suspect only a few places would need to do
this, like where we're holding one of the SLRU locks.  Some testing
would be needed to figure out exactly which places cause problems, but
that's why it's a good idea to start discussion of your proposed
feature before January 14th.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Andres Freund
Дата:
Сообщение: Re: WAL Rate Limiting