From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incomplete freezing when truncating a relation during vacuum |
Date: | 2013-12-01 20:38:18 |
Message-ID: | 09263396-0d78-4eb6-99f9-7fe74ea2bbfe@email.android.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> schrieb:
>Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> The VACUUM implementation in 9.3 had several bugs: It removed
>multixact
>> xmax values without regard of the importance of contained xids, it
>did
>> not remove multixacts if the contained xids were too old and it
>relied
>> on hint bits when checking whether a row needed to be frozen which
>might
>> not have been set on replicas.
>
>Uh ... what does the last have to do with it? Surely we don't run
>VACUUM on replicas. Or are you talking about what might happen when
>VACUUM is run on a former replica that's been promoted to master?
Unfortunately not. The problem is that xl_heap_freeze's redo function simply reexecutes heap-freeze-tuple() instead of logging much about each tuple...
Andres
--
Please excuse brevity and formatting - I am writing this on my mobile phone.
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2013-12-01 20:40:14 | Re: Handling GIN incomplete splits |
Previous Message | Tom Lane | 2013-12-01 20:27:44 | Re: Incomplete freezing when truncating a relation during vacuum |