Re: [HACKERS] freeze cannot be finished
Committed, thanks for the report! On 16.11.2013 22:05, Миша Тюрин wrote: Hello! Could anyone review patch suggested by Jeff Janes ? Initial thread http://www.postgresql.org/message-id/flat/1384356585.995240612%40f50.i.mail.ru Thanks in advance! On Wed, Nov 13, 2013 at 3:53 PM, Sergey Burladyan eshkin...@gmail.com wrote: Jeff Janes jeff.ja...@gmail.com writes: If I not mistaken, looks like lazy_scan_heap() called from lazy_vacuum_rel() (see [1]) skip pages, even if it run with scan_all == true, lazy_scan_heap() does not increment scanned_pages if lazy_check_needs_freeze() return false, so if this occurred at wraparound vacuum it cannot update pg_class, because pg_class updated via this code: new_frozen_xid = FreezeLimit; if (vacrelstats-scanned_pages vacrelstats-rel_pages) new_frozen_xid = InvalidTransactionId; vac_update_relstats(onerel, new_rel_pages, new_rel_tuples, new_rel_allvisible, vacrelstats-hasindex, new_frozen_xid); so i think in our prevent wraparound vacuum vacrelstats-scanned_pages always less than vacrelstats-rel_pages and pg_class relfrozenxid never updated. Yeah, I think that that is a bug. If the clean-up lock is unavailable but the page is inspected without it and found not to need freezing, then the page needs to be counted as scanned, but is not so counted. commit bbb6e559c4ea0fb4c346beda76736451dc24eb4e Date: Mon Nov 7 21:39:40 2011 -0500 But this was introduced in 9.2.0, so unless the OP didn't upgrade to 9.2 until recently, I don't know why it just started happening. It looks like a simple fix (to HEAD attached), but I don't know how to test it. Also, it seem like it might be worth issuing a warning if scan_all is true but all was not scanned. Cheers, Jeff -- Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org) To make changes to your subscription: https://urldefense.proofpoint.com/v1/url?u=http://www.postgresql.org/mailpref/pgsql-generalk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=xGch4oNJbpD%2BKPJECmgw4SLBhytSZLBX7UnkZhtNcpw%3D%0Am=n4tu%2Fhw2DBAVCLO0UwZqdJsniWyqjnPt3OK%2FqepXInw%3D%0As=ffa1f6d45b713d12b320b72a4f417015498f57305664de0da209dc32f5e8a63b -- -- - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] freeze cannot be finished
Hello!
Could anyone review patch suggested by Jeff Janes ?
Initial thread
http://www.postgresql.org/message-id/flat/1384356585.995240...@f50.i.mail.ru#1384356585.995240...@f50.i.mail.ru
Thanks in advance!
On Wed, Nov 13, 2013 at 3:53 PM, Sergey Burladyan eshkin...@gmail.com
wrote:
Jeff Janes jeff.ja...@gmail.com writes:
If I not mistaken, looks like lazy_scan_heap() called from lazy_vacuum_rel()
(see [1]) skip pages, even if it run with scan_all == true, lazy_scan_heap()
does not increment scanned_pages if lazy_check_needs_freeze() return false,
so
if this occurred at wraparound vacuum it cannot update pg_class, because
pg_class updated via this code:
new_frozen_xid = FreezeLimit;
if (vacrelstats-scanned_pages vacrelstats-rel_pages)
new_frozen_xid = InvalidTransactionId;
vac_update_relstats(onerel,
new_rel_pages,
new_rel_tuples,
new_rel_allvisible,
vacrelstats-hasindex,
new_frozen_xid);
so i think in our prevent wraparound vacuum vacrelstats-scanned_pages always
less than vacrelstats-rel_pages and pg_class relfrozenxid never updated.
Yeah, I think that that is a bug. If the clean-up lock is unavailable but
the page is inspected without it and found not to need freezing, then the
page needs to be counted as scanned, but is not so counted.
commit bbb6e559c4ea0fb4c346beda76736451dc24eb4e
Date: Mon Nov 7 21:39:40 2011 -0500
But this was introduced in 9.2.0, so unless the OP didn't upgrade to 9.2
until recently, I don't know why it just started happening.
It looks like a simple fix (to HEAD attached), but I don't know how to test
it.
Also, it seem like it might be worth issuing a warning if scan_all is true
but all was not scanned.
Cheers,
Jeff
--
Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
--
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
new file mode 100644
index e1d6d1c..6778c7d
*** a/src/backend/commands/vacuumlazy.c
--- b/src/backend/commands/vacuumlazy.c
*** lazy_scan_heap(Relation onerel, LVRelSta
*** 602,607
--- 602,608
if (!lazy_check_needs_freeze(buf))
{
UnlockReleaseBuffer(buf);
+ vacrelstats-scanned_pages++;
continue;
}
LockBuffer(buf, BUFFER_LOCK_UNLOCK);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
