From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Make HeapTupleSatisfiesMVCC more concurrent |
Date: | 2015-08-19 20:07:59 |
Message-ID: | CAMkU=1x-eQQ3D+h3SGhEE_YGNe-=ttB=F-j-A1H9gFG29ug4hA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 18, 2015 at 5:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2015-08-19 20:08:34 | Re: Our trial to TPC-DS but optimizer made unreasonable plan |
Previous Message | Marc Mamin | 2015-08-19 19:55:45 | Re: Declarative partitioning |