Re: Too rigorous assert in reorderbuffer.c

Arseny Sher writes: > I'm sorry to bother you with this again, but due to new test our > internal buildfarm revealed that ajacent assert on cmin is also lie. You > see, we can't assume cmin is stable because the same key (relnode, tid) > might refer to completely different tuples if tuple was i

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: > Thanks for checking! I also run it on all branches, everything passes. > Pushed now. I'm sorry to bother you with this again, but due to new test our internal buildfarm revealed that ajacent assert on cmin is also lie. You see, we can't assume cmin is stable because th

Re: Too rigorous assert in reorderbuffer.c

On 2019-Feb-12, Arseny Sher wrote: > > Alvaro Herrera writes: > > >> I thought the blanket removal of the assert() was excessive, and we can > >> relax it instead; what do you think of the attached? > > > > More precisely, my question was: with this change, does the code still > > work correctl

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: >> I thought the blanket removal of the assert() was excessive, and we can >> relax it instead; what do you think of the attached? > > More precisely, my question was: with this change, does the code still > work correctly in your non-toy case? Yes, it works. I thought f

Re: Too rigorous assert in reorderbuffer.c

On 2019-Feb-11, Alvaro Herrera wrote: > On 2019-Feb-07, Arseny Sher wrote: > > > Alvaro Herrera writes: > > > > Ah, okay. Does the test still fail when run without the code fix? > > > > Yes. The problem here is overriding cmax of catalog (pg_attribute in the > > test) tuples, so it fails with

Re: Too rigorous assert in reorderbuffer.c

On 2019-Feb-07, Arseny Sher wrote: > Alvaro Herrera writes: > > Ah, okay. Does the test still fail when run without the code fix? > > Yes. The problem here is overriding cmax of catalog (pg_attribute in the > test) tuples, so it fails without any data at all. Makes sense. I thought the blank

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: > On 2019-Feb-06, Arseny Sher wrote: > >> >> Alvaro Herrera writes: >> >> > note the additional pg_temp_XYZ row in the middle. This is caused by >> > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit >> > 325f2ec55; I don't think there's much to do in th

Re: Too rigorous assert in reorderbuffer.c

On 2019-Feb-06, Arseny Sher wrote: > > Alvaro Herrera writes: > > > note the additional pg_temp_XYZ row in the middle. This is caused by > > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit > > 325f2ec55; I don't think there's much to do in the backbranches other > > than hide

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: > note the additional pg_temp_XYZ row in the middle. This is caused by > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit > 325f2ec55; I don't think there's much to do in the backbranches other > than hide the pesky record to avoid it breaking the test.

Re: Too rigorous assert in reorderbuffer.c

On 2019-Jan-31, Arseny Sher wrote: > My colleague Alexander Lakhin has noticed an assertion failure in > reorderbuffer.c:1330. Here is a simple snippet reproducing it: > > SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', > 'test_decoding'); > > create table t(k int); > b

Re: Too rigorous assert in reorderbuffer.c

Hi, On 31.01.2019 9:21, Arseny Sher wrote: My colleague Alexander Lakhin has noticed an assertion failure in reorderbuffer.c:1330. Here is a simple snippet reproducing it: SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding'); create table t(k int); begin;