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

[HACKERS] On conflict update & hint bits

2016-09-30 Thread Konstantin Knizhnik
Hi, I am faced with rarely reproduced problem at our multimaster (and never at vanilla Postgres). We are using our own customized transaction manager, so it may be definitely the problem in our multimaster. But stack trace looks suspiciously and this is why I want to consult with people