Re: [HACKERS] On conflict update & hint bits

2016-10-24 Thread Kevin Grittner
On Sun, Oct 23, 2016 at 3:42 PM, Tom Lane wrote: > The business about not throwing a serialization failure due to actions > of our own xact does seem worth fixing now, but if I understand correctly, > we can deal with that by adding a test for xmin-is-our-own-xact into > the

Re: [HACKERS] On conflict update & hint bits

2016-10-24 Thread Tom Lane
Konstantin Knizhnik writes: > Just for information: I know that you are working on this issue, but as > far as we need to proceed further with our testing of multimaster, > I have done the following obvious changes and it fixes the problem (at > least this assertion

Re: [HACKERS] On conflict update & hint bits

2016-10-24 Thread Konstantin Knizhnik
On 24.10.2016 00:49, Peter Geoghegan wrote: On Sun, Oct 23, 2016 at 2:46 PM, Tom Lane wrote: What's bothering me is (a) it's less than 24 hours to release wrap and (b) this patch changes SSI-relevant behavior and hasn't been approved by Kevin. I'm not familiar enough

Re: [HACKERS] On conflict update & hint bits

2016-10-23 Thread Peter Geoghegan
On Sun, Oct 23, 2016 at 2:46 PM, Tom Lane wrote: > What's bothering me is (a) it's less than 24 hours to release wrap and > (b) this patch changes SSI-relevant behavior and hasn't been approved > by Kevin. I'm not familiar enough with that logic to commit a change > in it on

Re: [HACKERS] On conflict update & hint bits

2016-10-23 Thread Tom Lane
Peter Geoghegan writes: > On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane wrote: >> "Rarely" is not "never". A bigger problem though is that heap_fetch >> does more than just lock the buffer: there are also PredicateLockTuple >> and CheckForSerializableConflictOut

Re: [HACKERS] On conflict update & hint bits

2016-10-23 Thread Peter Geoghegan
On Sun, Oct 23, 2016 at 1:42 PM, Tom Lane wrote: > "Rarely" is not "never". A bigger problem though is that heap_fetch > does more than just lock the buffer: there are also PredicateLockTuple > and CheckForSerializableConflictOut calls in there. It's possible that > those

Re: [HACKERS] On conflict update & hint bits

2016-10-23 Thread Tom Lane
Peter Geoghegan writes: > On Sat, Oct 22, 2016 at 9:38 AM, Tom Lane wrote: >> 1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible >> call with ExecCheckTIDVisible? That appears to demand a re-fetch of the >> tuple ExecOnConflictUpdate

Re: [HACKERS] On conflict update & hint bits

2016-10-22 Thread Peter Geoghegan
On Sat, Oct 22, 2016 at 9:38 AM, Tom Lane wrote: > 1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible > call with ExecCheckTIDVisible? That appears to demand a re-fetch of the > tuple ExecOnConflictUpdate already has its hands on. Wouldn't it be >

Re: [HACKERS] On conflict update & hint bits

2016-10-22 Thread Tom Lane
Peter Geoghegan writes: > Attached is a revision of Thomas' patch to fix a related issue; it now > also fixes this no-buffer-lock-held issue. I think this needs more work. 1. Why are you replacing ExecOnConflictUpdate's ExecCheckHeapTupleVisible call with ExecCheckTIDVisible?

Re: [HACKERS] On conflict update & hint bits

2016-10-19 Thread Peter Geoghegan
On Sat, Oct 1, 2016 at 5:15 AM, Peter Geoghegan wrote: > On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik > wrote: >> So the question is whether it is correct that ExecOnConflictUpdate tries to >> access and update tuple without holding lock on the

Re: [HACKERS] On conflict update & hint bits

2016-10-02 Thread Peter Geoghegan
On Sat, Oct 1, 2016 at 1:15 PM, Peter Geoghegan wrote: > It also looks like the DO NOTHING variant is similarly affected, even > when the isolation level is READ COMMITTED.:-( Actually, the DO NOTHING variant is also only affected in isolation levels greater than READ

Re: [HACKERS] On conflict update & hint bits

2016-10-01 Thread Peter Geoghegan
On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik wrote: > So the question is whether it is correct that ExecOnConflictUpdate tries to > access and update tuple without holding lock on the buffer? You're right -- this is a bug in Postgres. I'm travelling from

Re: [HACKERS] On conflict update & hint bits

2016-09-30 Thread Konstantin Knizhnik
On 30.09.2016 19:37, Peter Geoghegan wrote: On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik wrote: Later we try to check tuple visibility: ExecCheckHeapTupleVisible(estate, , buffer); and inside HeapTupleSatisfiesMVCC try to set hint bit. So, you're

Re: [HACKERS] On conflict update & hint bits

2016-09-30 Thread Peter Geoghegan
On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik wrote: > Later we try to check tuple visibility: > > ExecCheckHeapTupleVisible(estate, , buffer); > > and inside HeapTupleSatisfiesMVCC try to set hint bit. So, you're using repeatable read or serializable