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 existing code structu
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 failure is not happen any mor
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 with that logic to commi
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 my own authority, esp
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 calls in there. It's possible that
>
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 are no-ops in this usag
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 already has its hands on. Wouldn't it
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
> better to just put a buff
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? That appears to de
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 buffer?
>
> You're right -- this is a bug in
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 COMMITTED. Not sure why
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 Ireland to the USA this weekend,
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, &tuple, buffer);
and inside HeapTupleSatisfiesMVCC try to set hint bit.
So, you're using repeatable read or
On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik
wrote:
> Later we try to check tuple visibility:
>
> ExecCheckHeapTupleVisible(estate, &tuple, buffer);
>
> and inside HeapTupleSatisfiesMVCC try to set hint bit.
So, you're using repeatable read or serializable isolation level?
--
Peter
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 famili
15 matches
Mail list logo
