Re: getting rid of freezing

On 05/25/2013 01:14 PM, Simon Riggs wrote:
> On 24 May 2013 17:00, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 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.
> 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
freezing
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Ü