Re: Old row version in hot chain become visible after a freeze

On Tue, Sep 12, 2017 at 5:22 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Michael Paquier wrote:
>> On Mon, Sep 11, 2017 at 11:01 PM, Alvaro Herrera
>> <alvherre@alvh.no-ip.org> wrote:
>> > (I also threw in a small sleep between heap_page_prune and
>> > HeapTupleSatisfiesVacuum while testing, just to widen the problem window
>> > to hopefully make any remaining problems more evident.)
>>
>> I am understanding that you mean heap_prepare_freeze_tuple here
>> instead of heap_page_prune.
>
> Hmm ... no, I meant adding a sleep after the page is pruned, before
> HeapTupleSatisfiesVacuum call that determines the action with regards to
> freezing.

Well, I have tested both. With the test case of Dan adding a sleep
after calling HeapTupleSatisfiesVacuum() helped in increasing the
window. Of course feel free to correct me.

>> Using again the test of Dan at the top of the thread, I am seeing from
>> time to time what looks like garbage data in xmax, like that:
>>  ctid  | xmin | xmax | id
>> -------+------+------+----
>>  (0,1) |  620 |    0 |  1
>>  (0,7) |  625 |   84 |  3
>> (2 rows)
>> [...]
>>  ctid  | xmin | xmax | id
>> -------+------+------+----
>>  (0,1) |  656 |    0 |  1
>>  (0,6) |  661 |  128 |  3
>> (2 rows)
>
> I bet those are multixact values rather than garbage.  You should see
> HEAP_XMAX_IS_MULTI in t_infomask in those cases, and the values should
> be near NextMultiXactId (make sure to checkpoint if you examine with
> pg_controldata; I think it's easier to obtain it from shmem.  Or you
> could just use pg_get_multixact_members()).

Yes, you're right. That's the case. So I guess that I don't have much
complains about the patch as presented.
-- 
Michael