public inbox for [email protected]help / color / mirror / Atom feed
Re: Lowering the default wal_blocksize to 4K 7+ messages / 5 participants [nested] [flat]
* Re: Lowering the default wal_blocksize to 4K @ 2026-02-16 21:13 Andres Freund <[email protected]> 0 siblings, 2 replies; 7+ messages in thread From: Andres Freund @ 2026-02-16 21:13 UTC (permalink / raw) To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> Hi, On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote: > > On Oct 10, 2023, at 02:08, Andres Freund <[email protected]> wrote: > > > > Hi, > > > > I've mentioned this to a few people before, but forgot to start an actual > > thread. So here we go: > > > > I think we should lower the default wal_blocksize / XLOG_BLCKSZ to 4096, from > > the current 8192. > > I prepared a patch in case we want to move with the default 4kb XLOG_BLCKSZ. I think we should. > Regarding reducing the page headers' size, the benefits of 4Kb wal_blocks > outweight disadvantages of the proportionally bigger header in my opinion. I agree. > Since we recycle WAL segments, the added size won't go to the disk usage but > rather cause a bit more freqent segment. I don't think that's a valid argument though, how much WAL needs to be archived is a relevant factor. > > One thing I noticed is that our auto-configuration of wal_buffers leads to > > different wal_buffers settings for different XLOG_BLCKSZ, which doesn't seem > > great. > > I don't think it's an issue as wal_buffers are in block units, not bytes. Even > though the auto-tuned number may change, the total amount of bytes still remains > the same with different XLOG_BLCKSZ. Given the way the auto-tuning works, I don't think that's true: /* * Auto-tune the number of XLOG buffers. * * The preferred setting for wal_buffers is about 3% of shared_buffers, with * a maximum of one XLOG segment (there is little reason to think that more * is helpful, at least so long as we force an fsync when switching log files) * and a minimum of 8 blocks (which was the default value prior to PostgreSQL * 9.1, when auto-tuning was added). * * This should not be called until NBuffers has received its final value. */ static int XLOGChooseNumBuffers(void) { int xbuffers; xbuffers = NBuffers / 32; if (xbuffers > (wal_segment_size / XLOG_BLCKSZ)) xbuffers = (wal_segment_size / XLOG_BLCKSZ); if (xbuffers < 8) xbuffers = 8; return xbuffers; } If NBuffers / 32 < wal_segment_size / XLOG_BLCKSZ, the chosen xbuffers value does not depend on XLOG_BLCKSZ. To me the code only makes sense if you assume that NBuffers / 32 gives you a value in the same domain as data blocks, otherwise NBuffers / 32 is not the approximation of %3 that the comment talks about. I think the code just needs to be fixed to multiply NBuffers * BLCKSZ and then divide that by XLOG_BLCKSZ. > > > For some example numbers, I ran a very simple insert workload with a varying > > number of clients with both a wal_blocksize=4096 and wal_blocksize=8192 > > cluster, and measured the amount of bytes written before/after. > > I've also run some simple tests on my local machine (Ubuntu in Vagrant on M1 > Mac). I run a sysbench write-only load for 20s with different amounts of threads > (and tables equal to the number of threads num) and measured disk writes with > iostat. I recreated tables and did a checkpoint before each run. These are my > results: > > 8Kb XLOG_BLCKSZ > ==== > Threads tps kB_wrtn > 1 535.34 207288 > 5 1457.24 591708 > 10 1441.85 574700 > 15 823.98 388732 > > 4Kb XLOG_BLCKSZ > ==== > Threads tps kB_wrtn > 1 542.02 153544 > 5 1556.83 393444 > 10 1288.00 339648 > 15 975.32 255708 The reduction in bytes written is rather impressive... > I will run more benchmarks on proper hardware. For example, interesting what > happens to performance with >4K writes. But what else do you think has to be > done to move this patch forward? I think the auto-tuning bit above needs to be fixed, and it's probably worth manually testing a pg_upgrade from 8kB XLOG_BLCKSZ to 4kB. It should work, but ... I think we otherwise should just go for it. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-02-17 07:26 Michael Paquier <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-02-17 07:26 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: Andy Pogrebnoi <[email protected]>; pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> On Mon, Feb 16, 2026 at 04:13:37PM -0500, Andres Freund wrote: > On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote: >> 8Kb XLOG_BLCKSZ >> ==== >> Threads tps kB_wrtn >> 1 535.34 207288 >> 5 1457.24 591708 >> 10 1441.85 574700 >> 15 823.98 388732 >> >> 4Kb XLOG_BLCKSZ >> ==== >> Threads tps kB_wrtn >> 1 542.02 153544 >> 5 1556.83 393444 >> 10 1288.00 339648 >> 15 975.32 255708 > > The reduction in bytes written is rather impressive... It's a pretty nice improvement for a change as simple as that, yes. +1. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-02-17 20:06 Andrew Pogrebnoi <[email protected]> parent: Andres Freund <[email protected]> 1 sibling, 1 reply; 7+ messages in thread From: Andrew Pogrebnoi @ 2026-02-17 20:06 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> Hi, On Mon, Feb 16, 2026 at 11:13 PM Andres Freund <[email protected]> wrote: > Hi, > > On 2026-02-16 10:04:37 +0200, Andy Pogrebnoi wrote: > > Since we recycle WAL segments, the added size won't go to the disk usage but > > rather cause a bit more freqent segment. > > I don't think that's a valid argument though, how much WAL needs to be > archived is a relevant factor. Yes, indeed. > If NBuffers / 32 < wal_segment_size / XLOG_BLCKSZ, the chosen xbuffers value > does not depend on XLOG_BLCKSZ. > > To me the code only makes sense if you assume that NBuffers / 32 gives you a > value in the same domain as data blocks, otherwise NBuffers / 32 is not the > approximation of %3 that the comment talks about. > > > I think the code just needs to be fixed to multiply NBuffers * BLCKSZ and then > divide that by XLOG_BLCKSZ. You are right, my bad, fixed (v2-0002). > I think the auto-tuning bit above needs to be fixed, and it's probably worth > manually testing a pg_upgrade from 8kB XLOG_BLCKSZ to 4kB. It should work, but pg_upgrade ran with no issues, and the database started with the new (4kB) XLOG_BLCKSZ I also found and fixed some more mentions of 8kB as the default for XLOG_BLCKSZ in the documentation (v2-0001). --- Cheers, Andy Attachments: [application/octet-stream] v2-0001-Change-default-wal_blocksize-to-4KB.patch (6.1K, 3-v2-0001-Change-default-wal_blocksize-to-4KB.patch) download | inline diff: From 63279ec5776d292ce3bde860ec987726a775dca9 Mon Sep 17 00:00:00 2001 From: Andrew Pogrebnoi <[email protected]> Date: Fri, 13 Feb 2026 16:14:45 +0200 Subject: [PATCH v2 1/2] Change default wal_blocksize to 4KB With the current 8KB default, we do more flushes of partially written buffers, which significantly increases the number of disk writes compared to 4KB XLOG_BLCKSZ. 4KB pages result in more overhead for headers, but it is small in comarison with the actual WAL data (~0.29% of space is headers with 8KB pages, and 0.59% with 4KB). See more on justification and benchmarks: https://www.postgresql.org/message-id/20231009230805.funj5ipoggjyzjz6%40awork3.anarazel.de --- configure | 4 ++-- configure.ac | 4 ++-- doc/src/sgml/config.sgml | 6 +++--- doc/src/sgml/installation.sgml | 4 ++-- doc/src/sgml/wal.sgml | 2 +- meson_options.txt | 2 +- 6 files changed, 11 insertions(+), 11 deletions(-) diff --git a/configure b/configure index ba293931878..06b50b61d25 100755 --- a/configure +++ b/configure @@ -1574,7 +1574,7 @@ Optional Packages: --with-segsize-blocks=SEGSIZE_BLOCKS set table segment size in blocks [0] --with-wal-blocksize=BLOCKSIZE - set WAL block size in kB [8] + set WAL block size in kB [4] --with-llvm build with LLVM based JIT support --without-icu build without ICU support --with-tcl build Tcl modules (PL/Tcl) @@ -3840,7 +3840,7 @@ if test "${with_wal_blocksize+set}" = set; then : esac else - wal_blocksize=8 + wal_blocksize=4 fi diff --git a/configure.ac b/configure.ac index 412fe358a2f..59678a7dd99 100644 --- a/configure.ac +++ b/configure.ac @@ -324,9 +324,9 @@ AC_DEFINE_UNQUOTED([RELSEG_SIZE], ${RELSEG_SIZE}, [ # WAL block size # AC_MSG_CHECKING([for WAL block size]) -PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [8]], +PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [4]], [wal_blocksize=$withval], - [wal_blocksize=8]) + [wal_blocksize=4]) case ${wal_blocksize} in 1) XLOG_BLCKSZ=1024;; 2) XLOG_BLCKSZ=2048;; diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index f1af1505cf3..f06de24bd04 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -3536,7 +3536,7 @@ include_dir 'conf.d' but any positive value less than <literal>32kB</literal> will be treated as <literal>32kB</literal>. If this value is specified without units, it is taken as WAL blocks, - that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB. + that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 4kB. This parameter can only be set at server start. </para> @@ -3596,7 +3596,7 @@ include_dir 'conf.d' flushed to disk. If <varname>wal_writer_flush_after</varname> is set to <literal>0</literal> then WAL data is always flushed immediately. If this value is specified without units, it is taken as WAL blocks, - that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB. + that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 4kB. The default is <literal>1MB</literal>. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. @@ -12146,7 +12146,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir' <para> Reports the size of a WAL disk block. It is determined by the value of <literal>XLOG_BLCKSZ</literal> when building the server. The default value - is 8192 bytes. + is 4096 bytes. </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index c903ccff988..6f3409406db 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1520,7 +1520,7 @@ build-postgresql: <listitem> <para> Set the <firstterm>WAL block size</firstterm>, in kilobytes. This is the unit - of storage and I/O within the WAL log. The default, 8 kilobytes, + of storage and I/O within the WAL log. The default, 4 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 64 (kilobytes). @@ -3047,7 +3047,7 @@ ninja install <listitem> <para> Set the <firstterm>WAL block size</firstterm>, in kilobytes. This is the unit - of storage and I/O within the WAL log. The default, 8 kilobytes, + of storage and I/O within the WAL log. The default, 4 kilobytes, is suitable for most situations; but other values may be useful in special cases. The value must be a power of 2 between 1 and 64 (kilobytes). diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index f3b86b26be9..731b8b6c6f0 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -881,7 +881,7 @@ <filename>pg_wal</filename> under the data directory, as a set of segment files, normally each 16 MB in size (but the size can be changed by altering the <option>--wal-segsize</option> <application>initdb</application> option). Each segment is - divided into pages, normally 8 kB each (this size can be changed via the + divided into pages, normally 4 kB each (this size can be changed via the <option>--with-wal-blocksize</option> configure option). The WAL record headers are described in <filename>access/xlogrecord.h</filename>; the record content is dependent on the type of event that is being logged. Segment diff --git a/meson_options.txt b/meson_options.txt index 6a793f3e479..22d936973d8 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -9,7 +9,7 @@ option('blocksize', type: 'combo', option('wal_blocksize', type: 'combo', choices: ['1', '2', '4', '8', '16', '32', '64'], - value: '8', + value: '4', description: 'WAL block size, in kilobytes') option('segsize', type: 'integer', value: 1, -- 2.43.0 [application/octet-stream] v2-0002-Fix-XLOG-buffers-auto-tune-for-different-XLOG_BLC.patch (942B, 4-v2-0002-Fix-XLOG-buffers-auto-tune-for-different-XLOG_BLC.patch) download | inline diff: From 72a70460d6966f9895ea874514c77a9405859057 Mon Sep 17 00:00:00 2001 From: Andrew Pogrebnoi <[email protected]> Date: Tue, 17 Feb 2026 21:12:21 +0200 Subject: [PATCH v2 2/2] Fix XLOG buffers auto-tune for different XLOG_BLCKSZ Before this change, XLOG buffers calculation in relation to shared_buffers made sense only if XLOG_BLCKSZ the same as BLCKSZ --- src/backend/access/transam/xlog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c index 13ec6225b85..d37e85a4077 100644 --- a/src/backend/access/transam/xlog.c +++ b/src/backend/access/transam/xlog.c @@ -4694,7 +4694,7 @@ XLOGChooseNumBuffers(void) { int xbuffers; - xbuffers = NBuffers / 32; + xbuffers = ((NBuffers * BLCKSZ) / XLOG_BLCKSZ) / 32; if (xbuffers > (wal_segment_size / XLOG_BLCKSZ)) xbuffers = (wal_segment_size / XLOG_BLCKSZ); if (xbuffers < 8) -- 2.43.0 ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-02-18 13:26 Andy Pogrebnoi <[email protected]> parent: Andrew Pogrebnoi <[email protected]> 0 siblings, 2 replies; 7+ messages in thread From: Andy Pogrebnoi @ 2026-02-18 13:26 UTC (permalink / raw) To: Andres Freund <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> Hi, The Windows tests are failing on `Assert("check_GUC_init(hentry->gucvar)")` for wal_writer_flush_after [1]. It doesn't make much sense to me as both load- and C-value for the wal_writer_flush_after GUC are the same constant: src/backend/utils/misc/guc_parameters.dat: { name => 'wal_writer_flush_after', type => 'int', context => 'PGC_SIGHUP', group => 'WAL_SETTINGS', short_desc => 'Amount of WAL written out by WAL writer that triggers a flush.', flags => 'GUC_UNIT_XBLOCKS', variable => 'WalWriterFlushAfter', boot_val => 'DEFAULT_WAL_WRITER_FLUSH_AFTER', min => '0', max => 'INT_MAX', }, src/include/postmaster/walwriter.h: int WalWriterFlushAfter = DEFAULT_WAL_WRITER_FLUSH_AFTER; This constant was introduced to fix the same issue [2], but I suppose no one checked Windows builds. Windows clearly has an old 8kB value for WalWriterFlushAfter during the check. I suppose it is something with the CI/build. But I have zero experience with building anything for Windows, so any tips on where to look are welcome. *And apologies for the dreadful formatting in my previous email; the client plays tricks on me after I hit Send. [1] https://cirrus-ci.com/task/6286650038288384?logs=test_world#L2728-L2729 [2] https://www.postgresql.org/message-id/[email protected]... --- Cheers, Andy ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-02-18 16:32 Andres Freund <[email protected]> parent: Andy Pogrebnoi <[email protected]> 1 sibling, 1 reply; 7+ messages in thread From: Andres Freund @ 2026-02-18 16:32 UTC (permalink / raw) To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> Hi, On 2026-02-18 15:26:24 +0200, Andy Pogrebnoi wrote: > The Windows tests are failing on `Assert("check_GUC_init(hentry->gucvar)")` > for wal_writer_flush_after [1]. It doesn't make much sense to me as both > load- and C-value for the wal_writer_flush_after GUC are the same constant: > > src/backend/utils/misc/guc_parameters.dat: > { name => 'wal_writer_flush_after', type => 'int', context => 'PGC_SIGHUP', > group => 'WAL_SETTINGS', > short_desc => 'Amount of WAL written out by WAL writer that triggers a > flush.', > flags => 'GUC_UNIT_XBLOCKS', > variable => 'WalWriterFlushAfter', > boot_val => 'DEFAULT_WAL_WRITER_FLUSH_AFTER', > min => '0', > max => 'INT_MAX', > }, > > src/include/postmaster/walwriter.h: > int WalWriterFlushAfter = DEFAULT_WAL_WRITER_FLUSH_AFTER; > > This constant was introduced to fix the same issue [2], but I suppose no > one checked Windows builds. Windows clearly has an old 8kB value for > WalWriterFlushAfter during the check. I suppose it is something with the > CI/build. But I have zero experience with building anything for Windows, so > any tips on where to look are welcome. The fact that the test do pass for msvc (which does not use ccache), but not for mingw (which uses ccache), does point towards some caching issue. We've had some caching problems on mingw before. I don't fully know what's going on, but there clearly is something wrong with ccache here when using precompiled headers, I can reproduce incomplete rebuilds with ccache's direct mode on linux, cross building for windows (first thing I tried). If I rebuild with a changed xlog blocksize, I get *some* cache hits building the backend, despite pg_config.h having changed. I think the problem is that ccache seems to not record a dependency to the pch file in its dependencies if the pch file is included via -include, if the included header and the header.h.gch file aren't in the same directory . That leads to the pch file getting rebuilt, but then ccache just uses the older cached result for the .c file getting built, because it does not recognize it would need to be rebuilt. I'll go and report that to the ccache folks. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-03-25 11:10 John Naylor <[email protected]> parent: Andy Pogrebnoi <[email protected]> 1 sibling, 0 replies; 7+ messages in thread From: John Naylor @ 2026-03-25 11:10 UTC (permalink / raw) To: Andy Pogrebnoi <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> On Wed, Feb 18, 2026 at 8:26 PM Andy Pogrebnoi <[email protected]> wrote: > The Windows tests are failing on `Assert("check_GUC_init(hentry->gucvar)")` for wal_writer_flush_after [1]. It doesn't make much sense to me as both load- and C-value for the wal_writer_flush_after GUC are the same constant: FWIW, they just started passing a couple days ago: https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F6490 -- John Naylor Amazon Web Services ^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Lowering the default wal_blocksize to 4K @ 2026-03-25 14:02 Andres Freund <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 0 replies; 7+ messages in thread From: Andres Freund @ 2026-03-25 14:02 UTC (permalink / raw) To: Andy Pogrebnoi <[email protected]>; +Cc: pgsql-hackers; Heikki Linnakangas <[email protected]>; Robert Haas <[email protected]>; Thomas Munro <[email protected]>; Matthias van de Meent <[email protected]> Hi, On 2026-02-18 11:32:28 -0500, Andres Freund wrote: > On 2026-02-18 15:26:24 +0200, Andy Pogrebnoi wrote: > > The Windows tests are failing on `Assert("check_GUC_init(hentry->gucvar)")` > > for wal_writer_flush_after [1]. It doesn't make much sense to me as both > > load- and C-value for the wal_writer_flush_after GUC are the same constant: > > > > src/backend/utils/misc/guc_parameters.dat: > > { name => 'wal_writer_flush_after', type => 'int', context => 'PGC_SIGHUP', > > group => 'WAL_SETTINGS', > > short_desc => 'Amount of WAL written out by WAL writer that triggers a > > flush.', > > flags => 'GUC_UNIT_XBLOCKS', > > variable => 'WalWriterFlushAfter', > > boot_val => 'DEFAULT_WAL_WRITER_FLUSH_AFTER', > > min => '0', > > max => 'INT_MAX', > > }, > > > > src/include/postmaster/walwriter.h: > > int WalWriterFlushAfter = DEFAULT_WAL_WRITER_FLUSH_AFTER; > > > > This constant was introduced to fix the same issue [2], but I suppose no > > one checked Windows builds. Windows clearly has an old 8kB value for > > WalWriterFlushAfter during the check. I suppose it is something with the > > CI/build. But I have zero experience with building anything for Windows, so > > any tips on where to look are welcome. > > The fact that the test do pass for msvc (which does not use ccache), but not > for mingw (which uses ccache), does point towards some caching issue. > > We've had some caching problems on mingw before. > > I don't fully know what's going on, but there clearly is something wrong with > ccache here when using precompiled headers, I can reproduce incomplete > rebuilds with ccache's direct mode on linux, cross building for windows (first > thing I tried). If I rebuild with a changed xlog blocksize, I get *some* cache > hits building the backend, despite pg_config.h having changed. > > > I think the problem is that ccache seems to not record a dependency to the pch > file in its dependencies if the pch file is included via -include, if the > included header and the header.h.gch file aren't in the same directory . That > leads to the pch file getting rebuilt, but then ccache just uses the older > cached result for the .c file getting built, because it does not recognize it > would need to be rebuilt. > > I'll go and report that to the ccache folks. I did that and forgot to update this thread: https://github.com/ccache/ccache/issues/1686 Unfortunately not much has happened on that front. But in the course of the investigation I discovered the gcc flag "fpch-deps". I think we should inject that in our build, if supported by the compiler. I don't really see a downside and it does avoid the issue at hand, based on my experiments. Greetings, Andres Freund ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-03-25 14:02 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-16 21:13 Re: Lowering the default wal_blocksize to 4K Andres Freund <[email protected]> 2026-02-17 07:26 ` Michael Paquier <[email protected]> 2026-02-17 20:06 ` Andrew Pogrebnoi <[email protected]> 2026-02-18 13:26 ` Andy Pogrebnoi <[email protected]> 2026-02-18 16:32 ` Andres Freund <[email protected]> 2026-03-25 14:02 ` Andres Freund <[email protected]> 2026-03-25 11:10 ` John Naylor <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox