Re: Testing autovacuum wraparound (including failsafe)

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: Testing autovacuum wraparound (including failsafe)
Date: 2023-03-03 11:34:50
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 16/11/2022 06:38, Ian Lawrence Barwick wrote:
> Thanks for the patch. While reviewing the patch backlog, we have determined that
> the latest version of this patch was submitted before meson support was
> implemented, so it should have a "" file added for consideration for
> inclusion in PostgreSQL 16.

I wanted to do some XID wraparound testing again, to test the 64-bit
SLRUs patches [1], and revived this.

I took a different approach to consuming the XIDs. Instead of setting
nextXID directly, bypassing GetNewTransactionId(), this patch introduces
a helper function to call GetNewTransactionId() repeatedly. But because
that's slow, it does include a shortcut to skip over "uninteresting"
XIDs. Whenever nextXid is close to an SLRU page boundary or XID
wraparound, it calls GetNewTransactionId(), and otherwise it bumps up
nextXid close to the next "interesting" value. That's still a lot slower
than just setting nextXid, but exercises the code more realistically.

I've written some variant of this helper function many times over the
years, for ad hoc testing. I'd love to have it permanently in the git tree.

In addition to Masahiko's test for emergency vacuum, this includes two
other tests. tests the "warn limit" and "stop limit" in
GetNewTransactionId(), and burns through 10 billion
transactions in total, exercising XID wraparound in general.
Unfortunately these tests are pretty slow; the tests run for about 4
minutes on my laptop in total, and use about 20 GB of disk space. So
perhaps these need to be put in a special test suite that's not run as
part of "check-world". Or perhaps leave out the test,
that's the slowest of the tests. But I'd love to have these in the git
tree in some form.


- Heikki

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2023-03-03 11:56:49 Re: Allow ordered partition scans in more cases
Previous Message Amit Kapila 2023-03-03 11:30:59 Re: Fix comments in gistxlogDelete, xl_heap_freeze_page and xl_btree_delete