Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 - Mailing list pgsql-general

From Jeff Janes
Subject Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Date
Msg-id CAMkU=1zYKfse5a-p6y0qDwGkT9tf8vFp2u3zebwPbUR5SfeP0g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1  (Steve Kehlet <steve.kehlet@gmail.com>)
List pgsql-general
On Wed, Jun 10, 2015 at 7:16 PM, Noah Misch <noah@leadboat.com> wrote:
On Mon, Jun 08, 2015 at 03:15:04PM +0200, Andres Freund wrote:
> One more thing:
> Our testing infrastructure sucks. Without writing C code it's basically
> impossible to test wraparounds and such. Even if not particularly useful
> for non-devs, I really think we should have functions for creating
> burning xids/multixacts in core. Or at least in some extension.

+1.  This keeps coming up, so it's worth maintaining a verified and speedy
implementation.

+1 from me as well.

Also, I've pretty much given up on testing this area myself, because of the issue pointed out here:


I think this is the same issue as part of Andres' point 1.

It is pretty frustrating and futile to test wrap around when the database doesn't live long enough to wrap around under the high-stress conditions.

I had thought that all changes to ShmemVariableCache except nextXid should be WAL logged at the time they occur, not just at the next checkpoint.  But that wouldn't fix the problem, as the change to ShmemVariableCache has to be transactional with the change to pg_database.  So it would have to be WAL logged inside the commit record or any transaction which changes pg_database.

Cheers,

Jeff

pgsql-general by date:

Previous
From: Jimmy Yih
Date:
Subject: Re: GCC error and libmpfr.so.4 not found
Next
From: Asma Riyaz
Date:
Subject: Re: GCC error and libmpfr.so.4 not found