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
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
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
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
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
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
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
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
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.
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
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;
Hi,
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;
savepoint a;
alter table t alter column k
12 matches
Mail list logo
