From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incomplete freezing when truncating a relation during vacuum |
Date: | 2013-11-27 09:01:55 |
Message-ID: | 5295B503.3050202@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/27/13 01:21, Andres Freund wrote:
> On 2013-11-26 13:32:44 +0100, Andres Freund wrote:
>> This seems to be the case since
>> b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. I suggest we go back to using
>> scan_all to determine whether we can set new_frozen_xid. That's a slight
>> pessimization when we scan a relation fully without explicitly scanning
>> it in its entirety, but given this isn't the first bug around
>> scanned_pages/rel_pages I'd rather go that way. The aforementioned
>> commit wasn't primarily concerned with that.
>> Alternatively we could just compute new_frozen_xid et al before the
>> lazy_truncate_heap.
>
> I've gone for the latter in this preliminary patch. Not increasing
> relfrozenxid after an initial data load seems like a bit of a shame.
>
> I wonder if we should just do scan_all || vacrelstats->scanned_pages <
> vacrelstats->rel_pages?
Hmm, you did (scan_all || vacrelstats->scanned_pages <
vacrelstats->rel_pages) for relminmxid, and just
(vacrelstats->scanned_pages < vacrelstats->rel_pages) for relfrozenxid.
That was probably not what you meant to do, the thing you did for
relfrozenxid looks good to me.
Does the attached look correct to you?
- Heikki
Attachment | Content-Type | Size |
---|---|---|
0001-Don-t-sometimes-incorrectly-increase-relfrozenxid-in-2.patch | text/x-diff | 2.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-11-27 09:02:02 | Re: Platform-dependent(?) failure in timeout handling |
Previous Message | Martijn van Oosterhout | 2013-11-27 08:23:29 | Re: Platform-dependent(?) failure in timeout handling |