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
|
Список | 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 по дате отправления: