Re: Direct I/O

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.