Re: MMAP Buffers
От | Robert Haas |
---|---|
Тема | Re: MMAP Buffers |
Дата | |
Msg-id | 69818AF1-FFFA-4015-BEF3-B3AB73F158BA@gmail.com обсуждение исходный текст |
Ответ на | Re: MMAP Buffers (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: MMAP Buffers
Re: MMAP Buffers |
Список | pgsql-hackers |
On Apr 16, 2011, at 1:48 AM, Greg Smith <greg@2ndquadrant.com> wrote: > P.S. You know what else I feel should earn an automatic rejection without any reviewer even looking at the code? Greg is absolutely right. And to the two he listed, let me add another of my own gripes: failing to provide submission notesthat explain how the patch works, and how it addresses the conceptually difficult issues raised previously. The OP saysthat this patch maintains the WAL-before-data rule without any explanation of how it accomplishes that seemingly quiteamazing feat. I assume I'm going to have to read this patch at some point to refute this assertion, and I think thatsucks. I am pretty nearly 100% confident that this approach is utterly doomed, and I don't want to spend a lot of timeon it unless someone can provide me with a compelling explanation of why my confidence is misplaced. But spending a lotof time on it is exactly what I'm going to have to do, because reading a undocumented patch full of spurious garbage torefute a hand-wavy claim of correctness is time-consuming, and if I give up on it without reading it, someone will yell"unfair, unfair!" None of this is to say that I don't appreciate Radoslaw's interest in contributing, because I very much do. But I also thinkit's important to realize that we have a finite number of reviewers and they have finite time. Trying to minimize theamount of time that it takes someone to review or commit your patch is a service to the whole community, and we shouldacknowledge that it has value and appreciate the people who consistently do it. ...Robert
В списке pgsql-hackers по дате отправления: