On Thu, 29 Jan 2026 at 20:16, Melanie Plageman <[email protected]> wrote: > > On Thu, Jan 29, 2026 at 8:39 AM Kirill Reshke <[email protected]> wrote: > > > > Thanks Alexander! > > This is a good and detailed report, I was able to reproduce this. > > Thanks to both of you for looking into it! > > > I have added some logs to my copy of postgres with your patch and I > > think problem causing this test to fail is this sequence: > > > > 1) Autovacuum starts, does its deeds, and acquiring xid = 118518 > > So, in this scenario, is the issue that autovacuum runs before vacuum > freeze? If so, we can change the table DDL to: > > create table test_vac_unmodified_heap(a int) with (autovacuum_enabled = > false); > > which would prevent the autovacuum from running. > > Unless there is some other way for one of the other tests to hold > OldestXmin back to before the xid of the insert. But I don't see how. > > > 2) insert into test_vac_unmodified_heap values (1); executes and > > commits with xid = 118519 (from my log) > > 3) vacuum freeze starts and computes cutoff xid = 118518, because > > oldest xmin is 118518 from (1) > > > > *and we cannot freeze tuple* > > - Melanie
Sorry, I messed up my previous email. > create table test_vac_unmodified_heap(a int) with (autovacuum_enabled = > false); Yes I did try this, but it does not help, because autovacuum runs on catalog relations, still causing fail. We cannot disable autovac globally in regression suite, so I propose to changes this to TAp test -- Best regards, Kirill Reshke
