Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do.
От | Simon Riggs |
---|---|
Тема | Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do. |
Дата | |
Msg-id | CA+U5nMKETN2Um8dsPhCm3T-axG_F9PyMmuZrgUArpX4dhrdDZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Avoid marking buffer dirty when VACUUM has no work to do. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Nov 22, 2011 at 2:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Simon Riggs <simon@2ndQuadrant.com> writes: >>> Avoid marking buffer dirty when VACUUM has no work to do. >>> When wal_level = 'hot_standby' we touched the last page of the >>> relation during a VACUUM, even if nothing else had happened. >>> That would alter the LSN of the last block and set the mtime >>> of the relation file unnecessarily. Noted by Thom Brown. > >> This doesn't look right to me --- you have not accounted for the >> possibility that btpo_cycleid or BTP_HAS_GARBAGE is changed. > >> Also, I'm confused about the business of not setting the LSN. Thom >> claimed that he was seeing the page not change at all (or at least >> md5sum of the file didn't change) despite mtime changing. If we'd >> been plastering a new LSN on the page each time, then that should >> certainly not have been possible. So I now think maybe we've >> mis-analyzed what was happening in his example. > >> I think this requires more careful analysis. > > Ping? If you don't respond, I'm going to take it on my own authority to > revert this patch, because it's definitely broken as-is, and I don't > think the consequences of not updating the page LSN have been thought > through either. Tom, waiting across a weekend isn't a cause for concern. I made that change for you, so am happy to revoke for you also. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: