On Sat, Apr 08, 2023 at 11:08:16AM -0700, Andres Freund wrote: > On 2023-04-07 23:04:08 -0700, Andres Freund wrote: > > There were some failures in CI (e.g. [1] (and perhaps also bf, didn't yet > > check), about "no unpinned buffers available". I was worried for a moment > > that this could actually be relation to the bulk extension patch. > > > > But it looks like it's older - and not caused by direct_io support (except > > by > > way of the test existing). I reproduced the issue locally by setting s_b > > even > > lower, to 16 and made the ERROR a PANIC. > > > > [backtrace]
I get an ERROR, not a PANIC: $ git rev-parse HEAD 2e57ffe12f6b5c1498f29cb7c0d9e17c797d9da6 $ git diff -U0 diff --git a/src/test/modules/test_misc/t/004_io_direct.pl b/src/test/modules/test_misc/t/004_io_direct.pl index f5bf0b1..8f0241b 100644 --- a/src/test/modules/test_misc/t/004_io_direct.pl +++ b/src/test/modules/test_misc/t/004_io_direct.pl @@ -25 +25 @@ io_direct = 'data,wal,wal_init' -shared_buffers = '256kB' # tiny to force I/O +shared_buffers = 16 $ ./configure -C --enable-debug --enable-cassert --enable-depend --enable-tap-tests --with-tcl --with-python --with-perl $ make -C src/test/modules/test_misc check PROVE_TESTS=t/004_io_direct.pl # +++ tap check in src/test/modules/test_misc +++ t/004_io_direct.pl .. Dubious, test returned 29 (wstat 7424, 0x1d00) No subtests run Test Summary Report ------------------- t/004_io_direct.pl (Wstat: 7424 Tests: 0 Failed: 0) Non-zero exit status: 29 Parse errors: No plan found in TAP output Files=1, Tests=0, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.41 cusr 0.14 csys = 0.56 CPU) Result: FAIL make: *** [../../../../src/makefiles/pgxs.mk:460: check] Error 1 $ grep pinned src/test/modules/test_misc/tmp_check/log/* src/test/modules/test_misc/tmp_check/log/004_io_direct_main.log:2023-04-08 21:12:46.781 PDT [929628] 004_io_direct.pl ERROR: no unpinned buffers available src/test/modules/test_misc/tmp_check/log/regress_log_004_io_direct:error running SQL: 'psql:<stdin>:1: ERROR: no unpinned buffers available' No good reason to PANIC there, so the path to PANIC may be fixable. > > If you look at log_newpage_range(), it's not surprising that we get this > > error > > - it pins up to 32 buffers at once. > > > > Afaics log_newpage_range() originates in 9155580fd5fc, but this caller is > > from > > c6b92041d385. > > Do we care about fixing this in the backbranches? Probably not, given there > > haven't been user complaints? I would not. This is only going to come up where the user goes out of the way to use near-minimum shared_buffers. > Here's a quick prototype of this approach. This looks fine. I'm not enthusiastic about incurring post-startup cycles to cater to allocating less than 512k*max_connections of shared buffers, but I expect the cycles in question are negligible here.
