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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs