public inbox for [email protected]help / color / mirror / Atom feed
Parallelizing startup with many databases 10+ messages / 4 participants [nested] [flat]
* Parallelizing startup with many databases @ 2026-01-02 07:55 Babak Ghadiri <[email protected]> 0 siblings, 2 replies; 10+ messages in thread From: Babak Ghadiri @ 2026-01-02 07:55 UTC (permalink / raw) To: [email protected] Hello, I hope you are doing well. In PostgreSQL 16, startup appears to initialize databases sequentially and primarily uses a single CPU core. In clusters with a very large number of databases (around 5,000 in our case), this results in noticeably long startup times after restarts or crash recovery. I would like to ask: - Is the largely single-threaded startup behavior a fundamental architectural constraint (e.g. catalog dependencies, locking, recovery ordering), or mainly an unimplemented optimization? - Are there any existing discussions, patches, versions (18+) to parallelize parts of startup or otherwise improve startup scalability with many databases? - Are there any PostgreSQL configuration settings known to dramatically reduce startup time, or is startup performance mostly fixed by architecture in this scenario? I understand that having many databases in a single cluster is not the most common or recommended multi-tenant model, but this is an existing system and I’m trying to better understand the current limits and future direction. Thank you for your time and insights. Best regards. ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-02 23:38 Andreas Karlsson <[email protected]> parent: Babak Ghadiri <[email protected]> 1 sibling, 1 reply; 10+ messages in thread From: Andreas Karlsson @ 2026-01-02 23:38 UTC (permalink / raw) To: Babak Ghadiri <[email protected]>; [email protected] On 1/2/26 8:55 AM, Babak Ghadiri wrote: > In PostgreSQL 16, startup appears to initialize databases sequentially and > primarily uses a single CPU core. In clusters with a very large number of > databases (around 5,000 in our case), this results in noticeably long > startup times after restarts or crash recovery. Have you measured what is actually causing the slow startup? Without knowing what is actually slow it is hard to say if threading would even help. How slow are we talking about and have you managed to create a minimal case for reproducing the issue? > - Is the largely single-threaded startup behavior a fundamental > architectural > constraint (e.g. catalog dependencies, locking, recovery ordering), > or mainly > an unimplemented optimization? PostgreSQL does not support threading, it uses a multi-process model to implement for example parallel queries. And there is no way threading would be introduced just to improved startup performance. > - Are there any existing discussions, patches, versions (18+) to > parallelize parts of startup or otherwise improve startup scalability > with many databases? Not as far as I am aware but you can search our archives. > - Are there any PostgreSQL configuration settings known to dramatically > reduce startup time, or is startup performance mostly fixed by > architecture in this scenario? I would first start trying to figure out why startup is slow before doing anything else. Andreas ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-03 00:02 Tom Lane <[email protected]> parent: Andreas Karlsson <[email protected]> 0 siblings, 0 replies; 10+ messages in thread From: Tom Lane @ 2026-01-03 00:02 UTC (permalink / raw) To: Andreas Karlsson <[email protected]>; +Cc: Babak Ghadiri <[email protected]>; [email protected] Andreas Karlsson <[email protected]> writes: > On 1/2/26 8:55 AM, Babak Ghadiri wrote: >> In PostgreSQL 16, startup appears to initialize databases sequentially and >> primarily uses a single CPU core. In clusters with a very large number of >> databases (around 5,000 in our case), this results in noticeably long >> startup times after restarts or crash recovery. > Have you measured what is actually causing the slow startup? Without > knowing what is actually slow it is hard to say if threading would even > help. "perf" results would likely be useful. I tried creating 5000 databases here and didn't notice any particular increase in server startup time (didn't try crash-recovery case). So whatever this is is likely somewhat configuration- or platform-dependent. Having said that, 5000 databases sounds like an anti-pattern to begin with. You're paying for an additional copy of the system catalogs for each one. regards, tom lane ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-03 00:58 Jelte Fennema-Nio <[email protected]> parent: Babak Ghadiri <[email protected]> 1 sibling, 1 reply; 10+ messages in thread From: Jelte Fennema-Nio @ 2026-01-03 00:58 UTC (permalink / raw) To: Babak Ghadiri <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On Fri, Jan 2, 2026, 08:55 Babak Ghadiri <[email protected]> wrote: > Hello, > I hope you are doing well. > > In PostgreSQL 16, startup appears to initialize databases sequentially and > primarily uses a single CPU core. In clusters with a very large number of > databases (around 5,000 in our case), this results in noticeably long > startup times after restarts or crash recovery. > You probably want to consider setting: recovery_init_sync_method=syncfs I'm 99% certain that that will solve your problem. https://www.postgresql.org/docs/current/runtime-config-error-handling.html https://www.postgresql.org/message-id/flat/[email protected] PS It took me way to long to find that setting. I think we should move it from the error handling docs page to the page with all of the other recovery settings. https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY > ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-03 19:09 Andreas Karlsson <[email protected]> parent: Jelte Fennema-Nio <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Andreas Karlsson @ 2026-01-03 19:09 UTC (permalink / raw) To: Jelte Fennema-Nio <[email protected]>; Babak Ghadiri <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]> On 1/3/26 1:58 AM, Jelte Fennema-Nio wrote: > PS It took me way to long to find that setting. I think we should move > it from the error handling docs page to the page with all of the other > recovery settings. https://www.postgresql.org/docs/current/runtime- > config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY <https://www.postgresql.org/ > docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY> I agree that it is currently not in exactly a great location but the issue is that the "Recovery" section is a subsection of the "WAL" section, and syncing the data directory is only loosely related to WAL. One could argue it is related to WAL as in that it is something done before replaying WAL but it is not an obvious location either. Or is it? Andreas ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-03 23:26 Jelte Fennema-Nio <[email protected]> parent: Andreas Karlsson <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Jelte Fennema-Nio @ 2026-01-03 23:26 UTC (permalink / raw) To: Andreas Karlsson <[email protected]>; [email protected]; +Cc: Babak Ghadiri <[email protected]> On Sat, 3 Jan 2026 at 20:09, Andreas Karlsson <[email protected]> wrote: > > On 1/3/26 1:58 AM, Jelte Fennema-Nio wrote: > > PS It took me way to long to find that setting. I think we should move > > it from the error handling docs page to the page with all of the other > > recovery settings. https://www.postgresql.org/docs/current/runtime- > > config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY <https://www.postgresql.org/ > > docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY> > > I agree that it is currently not in exactly a great location but the > issue is that the "Recovery" section is a subsection of the "WAL" > section, and syncing the data directory is only loosely related to WAL. > One could argue it is related to WAL as in that it is something done > before replaying WAL but it is not an obvious location either. Or is it? <Moving this discussion to pgsql-docs, with accompanying patch> While the setting is not strictly related to WAL it still seems a much more natural place than the "Error handling" page. Especially because of the description of this subheading: > This section describes the settings that apply to recovery in general, > affecting crash recovery, streaming replication and archive-based > replication. The only recovery related GUC that exists that's not on the WAL page is recovery_min_apply_delay, which is under the Replication->Standby section. Since that GUC is only valid on standbys that seems like a sensible choice. Attachments: [text/x-patch] v1-0001-docs-Move-recovery_init_sync_method-to-WAL-Recove.patch (5.9K, 2-v1-0001-docs-Move-recovery_init_sync_method-to-WAL-Recove.patch) download | inline diff: From 1ec7e36748ecf3d0c7e4333137c390658dc43e20 Mon Sep 17 00:00:00 2001 From: Jelte Fennema-Nio <[email protected]> Date: Sun, 4 Jan 2026 00:09:13 +0100 Subject: [PATCH v1] docs: Move recovery_init_sync_method to WAL->Recovery section The recovery_init_sync_method GUC was separated from all other recovery related GUCS in our docs. This made it pretty hard to find in the docs if you don't know exactly what you're looking for. This moves it to the generic "Recovery" section on the WAL page. While it's not really related to WAL it still seems a much more natural place than the "Error handling" page. Especially because of the description of this subheading: > This section describes the settings that apply to recovery in general, > affecting crash recovery, streaming replication and archive-based > replication. The only recovery related GUC that exists that's not on the WAL page is recovery_min_apply_delay, which is under the Replication->Standby section. Since that GUC is only valid on standbys that seems like a sensible choice. --- doc/src/sgml/config.sgml | 78 ++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index cdfe8e376f0..a38747c937e 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -3991,6 +3991,45 @@ include_dir 'conf.d' </listitem> </varlistentry> + <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method"> + <term><varname>recovery_init_sync_method</varname> (<type>enum</type>) + <indexterm> + <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + When set to <literal>fsync</literal>, which is the default, + <productname>PostgreSQL</productname> will recursively open and + synchronize all files in the data directory before crash recovery + begins. The search for files will follow symbolic links for the WAL + directory and each configured tablespace (but not any other symbolic + links). This is intended to make sure that all WAL and data files are + durably stored on disk before replaying changes. This applies whenever + starting a database cluster that did not shut down cleanly, including + copies created with <application>pg_basebackup</application>. + </para> + <para> + On Linux, <literal>syncfs</literal> may be used instead, to ask the + operating system to synchronize the file systems that contain the + data directory, the WAL files and each tablespace (but not any other + file systems that may be reachable through symbolic links). This may + be a lot faster than the <literal>fsync</literal> setting, because it + doesn't need to open each file one by one. On the other hand, it may + be slower if a file system is shared by other applications that + modify a lot of files, since those files will also be written to disk. + Furthermore, on versions of Linux before 5.8, I/O errors encountered + while writing data to disk may not be reported to + <productname>PostgreSQL</productname>, and relevant error messages may + appear only in kernel logs. + </para> + <para> + This parameter can only be set in the + <filename>postgresql.conf</filename> file or on the server command line. + </para> + </listitem> + </varlistentry> + </variablelist> </sect2> @@ -11714,45 +11753,6 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir' </listitem> </varlistentry> - <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method"> - <term><varname>recovery_init_sync_method</varname> (<type>enum</type>) - <indexterm> - <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary> - </indexterm> - </term> - <listitem> - <para> - When set to <literal>fsync</literal>, which is the default, - <productname>PostgreSQL</productname> will recursively open and - synchronize all files in the data directory before crash recovery - begins. The search for files will follow symbolic links for the WAL - directory and each configured tablespace (but not any other symbolic - links). This is intended to make sure that all WAL and data files are - durably stored on disk before replaying changes. This applies whenever - starting a database cluster that did not shut down cleanly, including - copies created with <application>pg_basebackup</application>. - </para> - <para> - On Linux, <literal>syncfs</literal> may be used instead, to ask the - operating system to synchronize the file systems that contain the - data directory, the WAL files and each tablespace (but not any other - file systems that may be reachable through symbolic links). This may - be a lot faster than the <literal>fsync</literal> setting, because it - doesn't need to open each file one by one. On the other hand, it may - be slower if a file system is shared by other applications that - modify a lot of files, since those files will also be written to disk. - Furthermore, on versions of Linux before 5.8, I/O errors encountered - while writing data to disk may not be reported to - <productname>PostgreSQL</productname>, and relevant error messages may - appear only in kernel logs. - </para> - <para> - This parameter can only be set in the - <filename>postgresql.conf</filename> file or on the server command line. - </para> - </listitem> - </varlistentry> - </variablelist> </sect1> base-commit: 094b61ce3ebbb1258675cb9b4eca9198628e2177 -- 2.52.0 ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-03 23:55 Andreas Karlsson <[email protected]> parent: Jelte Fennema-Nio <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Andreas Karlsson @ 2026-01-03 23:55 UTC (permalink / raw) To: Jelte Fennema-Nio <[email protected]>; [email protected]; +Cc: Babak Ghadiri <[email protected]> On 1/4/26 12:26 AM, Jelte Fennema-Nio wrote: > <Moving this discussion to pgsql-docs, with accompanying patch> If we move the GUC in the documentation shouldn't we also move it in postgresql.conf.sample? The sections in the documentation and the sections in the sample config file seem to be the same. Andreas ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-04 00:02 Tom Lane <[email protected]> parent: Andreas Karlsson <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Tom Lane @ 2026-01-04 00:02 UTC (permalink / raw) To: Andreas Karlsson <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; [email protected]; Babak Ghadiri <[email protected]> Andreas Karlsson <[email protected]> writes: > On 1/4/26 12:26 AM, Jelte Fennema-Nio wrote: >> <Moving this discussion to pgsql-docs, with accompanying patch> > If we move the GUC in the documentation shouldn't we also move it in > postgresql.conf.sample? The sections in the documentation and the > sections in the sample config file seem to be the same. You would also need to change the group that the GUC is assigned to in guc_parameters.dat. So this isn't really a docs-only patch. (I agree that the GUC seems misclassified as-is.) regards, tom lane ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-04 10:15 Jelte Fennema-Nio <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 10+ messages in thread From: Jelte Fennema-Nio @ 2026-01-04 10:15 UTC (permalink / raw) To: Tom Lane <[email protected]>; Andreas Karlsson <[email protected]>; +Cc: [email protected]; Babak Ghadiri <[email protected]> On Sun Jan 4, 2026 at 1:02 AM CET, Tom Lane wrote: > Andreas Karlsson <[email protected]> writes: >> On 1/4/26 12:26 AM, Jelte Fennema-Nio wrote: >>> <Moving this discussion to pgsql-docs, with accompanying patch> > >> If we move the GUC in the documentation shouldn't we also move it in >> postgresql.conf.sample? The sections in the documentation and the >> sections in the sample config file seem to be the same. > > You would also need to change the group that the GUC is assigned to > in guc_parameters.dat. So this isn't really a docs-only patch. > (I agree that the GUC seems misclassified as-is.) Good points. Attached an updated patch that changes postgresql.conf.sample and the group too. I didn't move the thread back to pgsql-hackers though, since changing the location once more seemed counterproductive. Especially since it's still a docs change at heart. Attachments: [text/x-patch] v2-0001-Move-recovery_init_sync_method-GUC-to-WAL_RECOVER.patch (8.1K, 2-v2-0001-Move-recovery_init_sync_method-GUC-to-WAL_RECOVER.patch) download | inline diff: From a5a7213ea2394208a2d69c1dcec26017948d2279 Mon Sep 17 00:00:00 2001 From: Jelte Fennema-Nio <[email protected]> Date: Sun, 4 Jan 2026 00:09:13 +0100 Subject: [PATCH v2] Move recovery_init_sync_method GUC to WAL_RECOVERY group The recovery_init_sync_method GUC was separated from all other recovery related GUCS in our docs. This made it pretty hard to find in the docs if you don't know exactly what you're looking for. This moves it to the generic "Recovery" section on the WAL page. While it's not really related to WAL it still seems a much more natural place than the "Error handling" page. Especially because of the description of this subheading: > This section describes the settings that apply to recovery in general, > affecting crash recovery, streaming replication and archive-based > replication. To make this doc change it also updates the group and place in postgresql.conf accordingly. The latter of which also required changing the section header in postgresql.conf.sample to match the header in the docs. The only recovery related GUC that exists that's not on the WAL page is recovery_min_apply_delay, which is under the Replication->Standby section. Since that GUC is only valid on standbys that seems like a sensible choice. --- doc/src/sgml/config.sgml | 78 +++++++++---------- src/backend/utils/misc/guc_parameters.dat | 2 +- src/backend/utils/misc/postgresql.conf.sample | 10 +-- 3 files changed, 45 insertions(+), 45 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index cdfe8e376f0..a38747c937e 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -3991,6 +3991,45 @@ include_dir 'conf.d' </listitem> </varlistentry> + <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method"> + <term><varname>recovery_init_sync_method</varname> (<type>enum</type>) + <indexterm> + <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary> + </indexterm> + </term> + <listitem> + <para> + When set to <literal>fsync</literal>, which is the default, + <productname>PostgreSQL</productname> will recursively open and + synchronize all files in the data directory before crash recovery + begins. The search for files will follow symbolic links for the WAL + directory and each configured tablespace (but not any other symbolic + links). This is intended to make sure that all WAL and data files are + durably stored on disk before replaying changes. This applies whenever + starting a database cluster that did not shut down cleanly, including + copies created with <application>pg_basebackup</application>. + </para> + <para> + On Linux, <literal>syncfs</literal> may be used instead, to ask the + operating system to synchronize the file systems that contain the + data directory, the WAL files and each tablespace (but not any other + file systems that may be reachable through symbolic links). This may + be a lot faster than the <literal>fsync</literal> setting, because it + doesn't need to open each file one by one. On the other hand, it may + be slower if a file system is shared by other applications that + modify a lot of files, since those files will also be written to disk. + Furthermore, on versions of Linux before 5.8, I/O errors encountered + while writing data to disk may not be reported to + <productname>PostgreSQL</productname>, and relevant error messages may + appear only in kernel logs. + </para> + <para> + This parameter can only be set in the + <filename>postgresql.conf</filename> file or on the server command line. + </para> + </listitem> + </varlistentry> + </variablelist> </sect2> @@ -11714,45 +11753,6 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir' </listitem> </varlistentry> - <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method"> - <term><varname>recovery_init_sync_method</varname> (<type>enum</type>) - <indexterm> - <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary> - </indexterm> - </term> - <listitem> - <para> - When set to <literal>fsync</literal>, which is the default, - <productname>PostgreSQL</productname> will recursively open and - synchronize all files in the data directory before crash recovery - begins. The search for files will follow symbolic links for the WAL - directory and each configured tablespace (but not any other symbolic - links). This is intended to make sure that all WAL and data files are - durably stored on disk before replaying changes. This applies whenever - starting a database cluster that did not shut down cleanly, including - copies created with <application>pg_basebackup</application>. - </para> - <para> - On Linux, <literal>syncfs</literal> may be used instead, to ask the - operating system to synchronize the file systems that contain the - data directory, the WAL files and each tablespace (but not any other - file systems that may be reachable through symbolic links). This may - be a lot faster than the <literal>fsync</literal> setting, because it - doesn't need to open each file one by one. On the other hand, it may - be slower if a file system is shared by other applications that - modify a lot of files, since those files will also be written to disk. - Furthermore, on versions of Linux before 5.8, I/O errors encountered - while writing data to disk may not be reported to - <productname>PostgreSQL</productname>, and relevant error messages may - appear only in kernel logs. - </para> - <para> - This parameter can only be set in the - <filename>postgresql.conf</filename> file or on the server command line. - </para> - </listitem> - </varlistentry> - </variablelist> </sect1> diff --git a/src/backend/utils/misc/guc_parameters.dat b/src/backend/utils/misc/guc_parameters.dat index cf87c09ca3b..13295737b49 100644 --- a/src/backend/utils/misc/guc_parameters.dat +++ b/src/backend/utils/misc/guc_parameters.dat @@ -2321,7 +2321,7 @@ boot_val => '""', }, -{ name => 'recovery_init_sync_method', type => 'enum', context => 'PGC_SIGHUP', group => 'ERROR_HANDLING_OPTIONS', +{ name => 'recovery_init_sync_method', type => 'enum', context => 'PGC_SIGHUP', group => 'WAL_RECOVERY', short_desc => 'Sets the method for synchronizing the data directory before crash recovery.', variable => 'recovery_init_sync_method', boot_val => 'DATA_DIR_SYNC_METHOD_FSYNC', diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index dc9e2255f8a..6e7472181b3 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -267,11 +267,12 @@ #max_wal_size = 1GB #min_wal_size = 80MB -# - Prefetching during recovery - +# - Recovery - -#recovery_prefetch = try # prefetch pages referenced in the WAL? -#wal_decode_buffer_size = 512kB # lookahead window used for prefetching - # (change requires restart) +#recovery_prefetch = try # prefetch pages referenced in the WAL? +#wal_decode_buffer_size = 512kB # lookahead window used for prefetching + # (change requires restart) +#recovery_init_sync_method = fsync # fsync, syncfs (Linux 5.8+) # - Archiving - @@ -868,7 +869,6 @@ #data_sync_retry = off # retry or panic on failure to fsync # data? # (change requires restart) -#recovery_init_sync_method = fsync # fsync, syncfs (Linux 5.8+) #------------------------------------------------------------------------------ base-commit: 094b61ce3ebbb1258675cb9b4eca9198628e2177 -- 2.52.0 ^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Parallelizing startup with many databases @ 2026-01-14 06:43 Andreas Karlsson <[email protected]> parent: Jelte Fennema-Nio <[email protected]> 0 siblings, 0 replies; 10+ messages in thread From: Andreas Karlsson @ 2026-01-14 06:43 UTC (permalink / raw) To: Jelte Fennema-Nio <[email protected]>; Tom Lane <[email protected]>; +Cc: [email protected]; Babak Ghadiri <[email protected]> On 1/4/26 11:15 AM, Jelte Fennema-Nio wrote: > Good points. Attached an updated patch that changes > postgresql.conf.sample and the group too. Nice, I think this makes things a lot clearer! Andreas ^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-01-14 06:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-02 07:55 Parallelizing startup with many databases Babak Ghadiri <[email protected]> 2026-01-02 23:38 ` Andreas Karlsson <[email protected]> 2026-01-03 00:02 ` Tom Lane <[email protected]> 2026-01-03 00:58 ` Jelte Fennema-Nio <[email protected]> 2026-01-03 19:09 ` Andreas Karlsson <[email protected]> 2026-01-03 23:26 ` Jelte Fennema-Nio <[email protected]> 2026-01-03 23:55 ` Andreas Karlsson <[email protected]> 2026-01-04 00:02 ` Tom Lane <[email protected]> 2026-01-04 10:15 ` Jelte Fennema-Nio <[email protected]> 2026-01-14 06:43 ` Andreas Karlsson <[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