On Fri, Nov 29, 2019 at 12:22 AM Mark Dilger <hornschnor...@gmail.com> wrote: > > Hackers, > > While working on the problem of XID wraparound within the LISTEN/NOTIFY > system, I tried to increment XIDs by more than one per transaction. > This leads to a number of test failures, many which look like: > > +ERROR: could not access status of transaction 7485 > +DETAIL: Could not read from file "pg_subtrans/0000" at offset 24576: > read too few bytes. > > I might not have read the right documentation, but.... > > I do not see anything in src/backend/access/transam/README nor elsewhere > documenting a design decision or assumption that transaction IDs must > be assigned contiguously. I suppose this is such a fundamental > assumption that it is completely implicit and nobody thought to document > it, but I'd like to check for two reasons: > > First, I'd like a good method of burning through transaction ids in > tests designed to check for problems in XID wrap-around. >
As Tom pointed out and as mentioned in the comments "If we are allocating the first XID of a new page of the commit log, zero out that commit-log page before returning.", we need to take care of extending the CLOG while advancing TransactionIds. I have some old script for burning transactionid's which I am attaching here. It might help you. I think this is provided long back by Jeff Janes. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
transactionid_burner_v1.patch
Description: Binary data