Re: getting rid of freezing
От | Simon Riggs |
---|---|
Тема | Re: getting rid of freezing |
Дата | |
Msg-id | CA+U5nMLGmJsumftGphnsmKptNa67CJn7dT_2=9BaQ43e0vFChw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: getting rid of freezing (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: getting rid of freezing
Re: getting rid of freezing |
Список | pgsql-hackers |
On 24 May 2013 17:00, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, May 24, 2013 at 11:29 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Fri, May 24, 2013 at 10:53 AM, Andres Freund <andres@2ndquadrant.com> wrote: >>>> [all-visible cannot restore hint bits without FPI because of torn pages] >>> >>> I haven't yet thought about this sufficiently yet. I think we might have >>> a chance of working around this, let me ponder a bit. >> >> Yeah. I too feel like there might be a solution. But I don't know >> have something specific in mind, yet anyway. > > One thought I had is that it might be beneficial to freeze when a page > ceases to be all-visible, rather than when it becomes all-visible. > Any operation that makes the page not-all-visible is going to emit an > FPI anyway, so we don't have to worry about torn pages in that case. > Under such a scheme, we'd have to enforce the rule that xmin and xmax > are ignored for any page that is all-visible; and when a page ceases > to be all-visible, we have to go back and really freeze the > pre-existing tuples. I think we might be able to use the existing > all_visible_cleared/new_all_visible_cleared flags to trigger this > behavior, without adding anything new to WAL at all. I like the idea but it would mean we'd have to freeze in the foreground path rather in a background path. Have we given up on the double buffering idea to remove FPIs completely? If we did that, then this wouldn't work. Anyway, I take it the direction of this idea is that "we don't need a separate freezemap, just use the vismap". That seems to be forcing ideas down a particular route we may regret. I'd rather just keep those things separate, even if we manage to merge the WAL actions for most of the time. Some other related thoughts: ISTM that if we really care about keeping xids for debug purposes that it could be a parameter. For the mainline, we just freeze blocks at the same time we do page pruning. I think the right way is actually to rethink and simplify all this complexity of Freezing/Pruning/Hinting/Visibility --Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: