Thread
Commits
-
pgstat: Hide instability in stats.spec with -DCATCACHE_FORCE_RELEASE.
- d6c0db14836c 15.0 landed
-
Fix test instability introduced in e349c95d3e9 due to async deduplication.
- dbe29b0d2c96 15.0 landed
-
test/isolation/expected/stats_1.out broken for me
Chapman Flack <chap@anastigmatix.net> — 2022-04-07T16:00:49Z
Running installcheck-world on an unrelated patch, I noticed a failure here in test/isolation/expected/stats_1.out (this is line 3102): step s1_slru_check_stats: SELECT current.blks_zeroed > before.value FROM test_slru_stats before INNER JOIN pg_stat_slru current ON before.slru = current.name WHERE before.stat = 'blks_zeroed'; ?column? -------- t (1 row) This is built from bab588c. On my amd64/linux box the result is f. The same mismatch is present if I build from 6392f2a (i.e., just before a2f433f pgstat: add alternate output for stats.spec), along with a bunch of others. So a2f433f seems to have silenced all the rest of those, but not this one. If I build from ad40166, installcheck-world passes. That's as far as I have pursued it. Regards, -Chap -
Re: test/isolation/expected/stats_1.out broken for me
Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-07T16:49:07Z
chap@anastigmatix.net writes: > Running installcheck-world on an unrelated patch, I noticed a failure > here in test/isolation/expected/stats_1.out (this is line 3102): So what non-default build options are you using? The only isolationcheck failure remaining in the buildfarm is prion's, which I can reproduce here by building with -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE as it does. Looking at the nature of the diffs, this is not too surprising; the expected output appears to rely on a cache flush not happening quickly in s2. regards, tom lane
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T16:57:09Z
Hi, On 2022-04-07 12:49:07 -0400, Tom Lane wrote: > chap@anastigmatix.net writes: > > Running installcheck-world on an unrelated patch, I noticed a failure > > here in test/isolation/expected/stats_1.out (this is line 3102): > > So what non-default build options are you using? > > The only isolationcheck failure remaining in the buildfarm is > prion's, which I can reproduce here by building with > -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE as it does. > Looking at the nature of the diffs, this is not too surprising; > the expected output appears to rely on a cache flush not happening > quickly in s2. Yea :(. I tested debug_discard_caches, but not -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE. Not quite sure what to do about it - it's intentionally trying to test the case of no invalidations being processed, as that's an annoying edge case with functions. Perhaps wrapping the function call of the "already dropped" function in another function that catches the error would do the trick? It'd be more easily silently broken, but still be better than not having the test. Greetings, Andres Freund
-
Re: test/isolation/expected/stats_1.out broken for me
Chapman Flack <chap@anastigmatix.net> — 2022-04-07T17:16:53Z
On 2022-04-07 12:49, Tom Lane wrote: > So what non-default build options are you using? The command that I've just been reusing from my bash_history without thinking about it for some years is: configure --enable-cassert --enable-tap-tests \ --with-libxml --enable-debug \ CFLAGS='-ggdb -Og -g3 -fno-omit-frame-pointer' Regards, -Chap
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T17:29:10Z
Hi, On 2022-04-07 13:16:53 -0400, chap@anastigmatix.net wrote: > The command that I've just been reusing from my bash_history without > thinking about it for some years is: > > configure --enable-cassert --enable-tap-tests \ > --with-libxml --enable-debug \ > CFLAGS='-ggdb -Og -g3 -fno-omit-frame-pointer' Hm, that's similar to what I use without seeing the problem. IIUC you ran installcheck - did you set any non-default config options in the postgres instance that runs against? Is anything else running on that instance? Do you use any -j setting when running installcheck-world? Is the failure reproducible, or a one-off? Greetings, Andres Freund
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T18:02:41Z
Hi, On 2022-04-07 10:29:10 -0700, Andres Freund wrote: > On 2022-04-07 13:16:53 -0400, chap@anastigmatix.net wrote: > > The command that I've just been reusing from my bash_history without > > thinking about it for some years is: > > > > configure --enable-cassert --enable-tap-tests \ > > --with-libxml --enable-debug \ > > CFLAGS='-ggdb -Og -g3 -fno-omit-frame-pointer' > > Hm, that's similar to what I use without seeing the problem. > > IIUC you ran installcheck - did you set any non-default config options in the > postgres instance that runs against? Is anything else running on that > instance? Do you use any -j setting when running installcheck-world? > > Is the failure reproducible, or a one-off? I've now reproduced this, albeit not reliably yet. Looking. Greetings, Andres Freund
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T18:54:08Z
Hi, On 2022-04-07 11:02:41 -0700, Andres Freund wrote: > I've now reproduced this, albeit not reliably yet. Looking. Caused by me misremembering when deduplication happens - somehow recalled that deduplication didn't happen when payloads. So the statement that was supposed to guarantee needing more than one page: SELECT pg_notify('stats_test_use', repeat('0', current_setting('block_size')::int / 2)) FROM generate_series(1, 3); didn't actually guarantee that. It just failed to fail by chance. When regression tests and isolation test run in sequence against the same freshly started cluster, the offsets when starting out are just right to not need another page in the first test. I'll change it to use distinct payloads.. Greetings, Andres Freund -
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T19:04:25Z
Hi, On 2022-04-07 11:54:08 -0700, Andres Freund wrote: > I'll change it to use distinct payloads.. And done. Chap, could you confirm this fixes the issue for you? Greetings, Andres Freund
-
Re: test/isolation/expected/stats_1.out broken for me
Chapman Flack <chap@anastigmatix.net> — 2022-04-07T21:14:54Z
On 2022-04-07 15:04, Andres Freund wrote: > And done. Chap, could you confirm this fixes the issue for you? Looks good from here. One installcheck-world with no failures; previously, it failed for me every time. Regards, -Chap
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-07T22:02:45Z
Hi, On 2022-04-07 09:57:09 -0700, Andres Freund wrote: > Yea :(. I tested debug_discard_caches, but not -DRELCACHE_FORCE_RELEASE > -DCATCACHE_FORCE_RELEASE. > > Not quite sure what to do about it - it's intentionally trying to test the > case of no invalidations being processed, as that's an annoying edge case with > functions. Perhaps wrapping the function call of the "already dropped" > function in another function that catches the error would do the trick? It'd > be more easily silently broken, but still be better than not having the test. Anybody got a better idea? - Andres
-
Re: test/isolation/expected/stats_1.out broken for me
Tom Lane <tgl@sss.pgh.pa.us> — 2022-04-07T22:31:35Z
Andres Freund <andres@anarazel.de> writes: > On 2022-04-07 09:57:09 -0700, Andres Freund wrote: >> Yea :(. I tested debug_discard_caches, but not -DRELCACHE_FORCE_RELEASE >> -DCATCACHE_FORCE_RELEASE. >> >> Not quite sure what to do about it - it's intentionally trying to test the >> case of no invalidations being processed, as that's an annoying edge case with >> functions. Perhaps wrapping the function call of the "already dropped" >> function in another function that catches the error would do the trick? It'd >> be more easily silently broken, but still be better than not having the test. > Anybody got a better idea? Maybe if the wrapper function checks for exactly the two expected behaviors, it'd be robust enough? regards, tom lane
-
Re: test/isolation/expected/stats_1.out broken for me
Andres Freund <andres@anarazel.de> — 2022-04-08T01:22:57Z
Hi, On 2022-04-07 18:31:35 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2022-04-07 09:57:09 -0700, Andres Freund wrote: > >> Yea :(. I tested debug_discard_caches, but not -DRELCACHE_FORCE_RELEASE > >> -DCATCACHE_FORCE_RELEASE. > >> > >> Not quite sure what to do about it - it's intentionally trying to test the > >> case of no invalidations being processed, as that's an annoying edge case with > >> functions. Perhaps wrapping the function call of the "already dropped" > >> function in another function that catches the error would do the trick? It'd > >> be more easily silently broken, but still be better than not having the test. > > > Anybody got a better idea? > > Maybe if the wrapper function checks for exactly the two expected > behaviors, it'd be robust enough? Seems to work. If I break the code it's trying to test, it still fails... Of course only when none of debug_discard_caches, RELCACHE_FORCE_RELEASE, CATCACHE_FORCE_RELEASE are used, but that seems unavoidable / harmless. Let's see what the buildfarm thinks. Greetings, Andres Freund