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
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
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
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
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
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
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
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
>
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?
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
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
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
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
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
14 matches
Mail list logo