On Fri, Nov 29, 2019 at 12:22 AM Mark Dilger <hornschnorter@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
