Re: Updated posix fadvise patch v19
От
Peter Eisentraut
Тема
Re: Updated posix fadvise patch v19
Дата
Msg-id
4922DB2E.6060509@gmx.net
Ответ на
Re: Updated posix fadvise patch v19 (Gregory Stark)
Список
Дерево обсуждения
Updated posix fadvise patch v19 Gregory Stark <stark@enterprisedb.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 Gregory Stark <stark@enterprisedb.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 Greg Smith <gsmith@gregsmith.com>
Re: Updated posix fadvise patch v19 Gregory Stark <stark@enterprisedb.com>
Re: Updated posix fadvise patch v19 Peter Eisentraut <peter_e@gmx.net>
Re: Updated posix fadvise patch v19 Gregory Stark <stark@enterprisedb.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 Gregory Stark <stark@enterprisedb.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 "Robert Haas" <robertmhaas@gmail.com>
Re: Updated posix fadvise patch v19 Grzegorz Jaskiewicz <gj@pointblue.com.pl>
Re: Updated posix fadvise patch v19 Grzegorz Jaskiewicz <gj@pointblue.com.pl>
Gregory Stark wrote: > The XXX is something that probably needs to be fixed but it's just a question > of what header file to put a declaration in. I couldn't find a good choice but > perhaps someone else has an idea? > > For the FIXMEs I don't have any problem leaving them in place. They're > warnings to future coders working in the same area of what they may have to do > to make the code more general. In particular both FIXMEs are related to memory > management of the iterator structures. I think just allocating them in the > bitmap memory context is fine for existing callers. I would rather leave them > there because I would like a reviewer to double check that we don't have a > memory leak there. There are probably no rigid rules on this, but my interpretation of these tags is usually this: XXX -- not sure if this is the best way to do this, needs ideas TODO -- specific ideas for improvement FIXME -- broken, must be fixed to be usable So committed code should probably not contain any FIXMEs, but possibly some of the others. I usually label stubs in work-in-progress code with // FIXME and then check if I removed them all before proposing a patch for inclusion. But those are just my ideas ...
В списке pgsql-hackers по дате отправления
От: Zdenek Kotala
Дата: