From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reviewing freeze map code |
Date: | 2016-06-14 12:44:44 |
Message-ID: | CA+Tgmob+jC=3LUSSQ0ojA02naKC6yb8ny-SHZp8rEFi8Y-X=BA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 14, 2016 at 8:11 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I noticed that the tuples that it reported were always offset 1 in a
>>> page, and that the page always had a maxoff over a couple of hundred,
>>> and that we called record_corrupt_item because VM_ALL_VISIBLE returned
>>> true but HeapTupleSatisfiesVacuum on the first tuple returned
>>> HEAPTUPLE_DELETE_IN_PROGRESS instead of the expected HEAPTUPLE_LIVE.
>>> It did that because HEAP_XMAX_COMMITTED was not set and
>>> TransactionIdIsInProgress returned true for xmax.
>>
>> So this seems like it might be a visibility map bug rather than a bug
>> in the test code, but I'm not completely sure of that. How was it
>> legitimate to mark the page as all-visible if a tuple on the page
>> still had a live xmax? If xmax is live and not just a locker then the
>> tuple is not visible to the transaction that wrote xmax, at least.
>
> Ah, wait a minute. I see how this could happen. Hang on, let me
> update the pg_visibility patch.
The problem should be fixed in the attached revision of
pg_check_visible. I think what happened is:
1. pg_check_visible computed an OldestXmin.
2. Some transaction committed.
3. VACUUM computed a newer OldestXmin and marked a page all-visible with it.
4. pg_check_visible then used its older OldestXmin to check the
visibility of tuples on that page, and saw delete-in-progress as a
result.
I added a guard against a similar scenario involving xmin in the last
version of this patch, but forgot that we need to protect xmax in the
same way. With this version of the patch, I can no longer get any
TIDs to pop up out of pg_check_visible in my testing. (I haven't run
your test script for lack of the proper Python environment...)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
check-visibility-v5.patch | text/x-diff | 20.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bernd Helmle | 2016-06-14 12:46:06 | Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column |
Previous Message | Michael Paquier | 2016-06-14 12:24:58 | Re: [BUG] pg_basebackup from disconnected standby fails |