On 05/25/2013 01:14 PM, Simon Riggs wrote:
On 24 May 2013 17:00, Robert Haas wrote:
On Fri, May 24, 2013 at 11:29 AM, Robert Haas wrote:
On Fri, May 24, 2013 at 10:53 AM, Andres Freund 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
I think that tis xmin, xmax business is mainly leftovers from the time when
PostgreSQL was a full history database. If we are happy to descide that we
do not want to resurrect this feature, at least not the same way, then
at the earliest or most convenient possibility seems the way to go .

The "forensic" part has always been just a nice side effect of this
design and
not the main design considerataion.

Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 17 of 26 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 23, '13 at 5:51p
activeJun 1, '13 at 5:56p



site design / logo © 2021 Grokbase