From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: getting rid of freezing |
Date: | 2013-05-24 16:00:00 |
Message-ID: | CA+TgmoZz8H8LJgKdAf61L+XefU+pYnXqMoUpzYSEhwStAuJqFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 24, 2013 at 11:29 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, May 24, 2013 at 10:53 AM, Andres Freund <andres(at)2ndquadrant(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-05-24 16:11:49 | Re: getting rid of freezing |
Previous Message | Andres Freund | 2013-05-24 15:52:19 | Re: getting rid of freezing |