Re: Odd, intermittent failure in contrib/pageinspect
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Michael Paquier <michael@paquier.xyz>,
pgsql-hackers@lists.postgresql.org
Date: 2021-01-20T01:57:22Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > I think you don't event need checkpointer to be involved, normal buffer > replacement would do the trick. We briefly pin the page in BufferAlloc() > even if the page is clean. Longer when it's dirty, of course. True, but it seems unlikely that the pages in question here would be chosen as replacement victims. These are non-parallel tests, so there's little competitive pressure. I could believe that a background autovacuum is active, but not that it's dirtied so many pages that tables the test script just created need to get swapped out. The checkpointer theory seems good because it requires no assumptions at all about competing demand for buffers. If the clock sweep gets to the table page (which we know is recently dirtied) at just the right time, we'll see a failure. regards, tom lane
Commits
-
Disable vacuum page skipping in selected test cases.
- c2dc1a79767a 14.0 landed
- a57dbfcda553 13.2 landed
- 6a97ca31288d 11.11 landed
- 53a24faaa403 12.6 landed
- 3ae247d40231 10.16 landed