Re: Make HeapTupleSatisfiesMVCC more concurrent
От | Jeff Janes |
---|---|
Тема | Re: Make HeapTupleSatisfiesMVCC more concurrent |
Дата | |
Msg-id | CAMkU=1x-eQQ3D+h3SGhEE_YGNe-=ttB=F-j-A1H9gFG29ug4hA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make HeapTupleSatisfiesMVCC more concurrent (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Aug 18, 2015 at 5:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> Just thinking about this ... I wonder why we need to call
> TransactionIdIsInProgress() at all rather than believing the answer from
> the snapshot? Under what circumstances could TransactionIdIsInProgress()
> return true where XidInMVCCSnapshot() had not?
I experimented with the attached patch, which replaces
HeapTupleSatisfiesMVCC's calls of TransactionIdIsInProgress with
XidInMVCCSnapshot, and then as a cross-check has all the "return false"
exits from XidInMVCCSnapshot assert !TransactionIdIsInProgress().
The asserts did not fire in the standard regression tests nor in a
pgbench run, which is surely not proof of anything but it suggests
that I'm not totally nuts.
I wouldn't commit the changes in XidInMVCCSnapshot for real, but
otherwise this is a possibly committable patch.
This gives the same performance improvement as the original patch (when compiled without cassert).
It has survived testing in a hostile environment (rapid fire stream of contentious updates intermixed with selects, with or without frequent crashes) without signs of missed or duplicated rows.
So, it looks good to me.
Cheers,
Jeff
В списке pgsql-hackers по дате отправления: