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