Re: WAL Rate Limiting
От
Greg Stark
Тема
Re: WAL Rate Limiting
Дата
Msg-id
CAM-w4HNq8LZFrAqJ1BM5_H2xiADnF+Mnurk8TnDX3rd9hffPSQ@mail.gmail.com
Ответ на
Re: WAL Rate Limiting (Simon Riggs)
Список
Дерево обсуждения
WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Craig Ringer <craig@2ndquadrant.com>
Re: WAL Rate Limiting Jim Nasby <jim@nasby.net>
Re: WAL Rate Limiting Peter Eisentraut <peter_e@gmx.net>
Re: WAL Rate Limiting Pavan Deolasee <pavan.deolasee@gmail.com>
Re: WAL Rate Limiting Magnus Hagander <magnus@hagander.net>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Tom Lane <tgl@sss.pgh.pa.us>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Heikki Linnakangas <hlinnakangas@vmware.com>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Tom Lane <tgl@sss.pgh.pa.us>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Tom Lane <tgl@sss.pgh.pa.us>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Jeff Janes <jeff.janes@gmail.com>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Tom Lane <tgl@sss.pgh.pa.us>
Re: WAL Rate Limiting Heikki Linnakangas <hlinnakangas@vmware.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Greg Stark <stark@mit.edu>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Greg Stark <stark@mit.edu>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Alvaro Herrera <alvherre@2ndquadrant.com>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Alvaro Herrera <alvherre@2ndquadrant.com>
Re: WAL Rate Limiting Hannu Krosing <hannu@2ndQuadrant.com>
Re: WAL Rate Limiting Greg Stark <stark@mit.edu>
Re: WAL Rate Limiting Robert Haas <robertmhaas@gmail.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Andres Freund <andres@2ndquadrant.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Heikki Linnakangas <hlinnakangas@vmware.com>
Re: WAL Rate Limiting Simon Riggs <simon@2ndQuadrant.com>
Re: WAL Rate Limiting Tom Lane <tgl@sss.pgh.pa.us>
Re: WAL Rate Limiting Craig Ringer <craig@2ndquadrant.com>
Re: WAL Rate Limiting Jim Nasby <jim@nasby.net>
On Thu, Feb 20, 2014 at 1:45 PM, Simon Riggs wrote: > On 19 February 2014 16:04, Robert Haas wrote: > >> Well, *I* don't think this is ready to go. A WAL rate limit that only >> limits WAL sometimes still doesn't impress me. > > Could you be specific in your criticism? "Sometimes" wouldn't impress > anybody, but we need to understand whether you are referring to a bug > or just making a personal assessment of the patch features. Thanks. I think it's clear what the question here is. The patch represents a quick easy win for certain cases but isn't the nice broad solution we would prefer to have. We face this decision a lot and it's a tough one. On the one hand we want to set a high standard for ourselves and not load up the Postgres source with lots of half-measures, on the other hand we don't want to let "perfect be the enemy of the good" and have development stall while we refuse easy wins. I don't think it would be a terrible thing if this patch went in. And I also don't think it would be a huge loss if it didn't since I think we will need IO resource management down the road anyways. I was looking for a few non-controversial patches to work on at least at the moment to establish some history before I take on more controversial patches so I don't think committing this is really a great idea for me right now. If you wanted to make this a more general system I have some ideas and I think we could do it fairly easily. We could make CHECK_FOR_INTERRUPTS have a single flag but if it's set check the "interrupt type" and know that some types can be handled by simply sleeping and not throwing an error. There are already some cases that are handled specially so it wouldn't really even change the code much. I would be happy to help get something like that committed. -- greg
В списке pgsql-hackers по дате отправления