On Tue, May 28, 2013 at 7:27 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-05-28 09:39:13 -0700, Josh Berkus wrote:
>> On 05/28/2013 06:21 AM, Robert Haas wrote:
>> > As a general statement, I view this work as something that is likely
>> > needed no matter which one of the "remove freezing" approaches that
>> > have been proposed we choose to adopt. It does not fix anything in
>> > and of itself, but it (hopefully) removes an objection to the entire
>> > line of inquiry.
>>
>> Agreed. I have some ideas on how to reduce the impact of freezing as
>> well (of course), and the description of your approach certainly seems
>> to benefit them, especially as it removes the whole "forensic
>> information" objection.
>>
>> One question though: if we're not removing the xmin, how do we know the
>> maximum xid to which we can prune clog? I can imagine several ways
>> given your approach.
>
> Simply don't count xids which are frozen. Currently we ignore an xid
> because its a special value, after this because the tuple has a certain
> hint bit (combination) set.
Right, what he said. Calculating the XID before which we no longer
need CLOG is just a matter of looking at all the tuples that we don't
know to be frozen and taking the oldest XID from among those. This
patch changes the definition of "frozen" but that's a pretty minor
detail of the CLOG-truncation calculation. So, in essence, this patch
doesn't really make much difference in that area either way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company