Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vbpye-00EJTr-1G for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Jan 2026 00:58:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vbpyc-00BiD5-0x for pgsql-hackers@arkaria.postgresql.org; Sat, 03 Jan 2026 00:58:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vbpyb-00BiCv-3A for pgsql-hackers@lists.postgresql.org; Sat, 03 Jan 2026 00:58:42 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vbpyZ-004AKT-2W for pgsql-hackers@lists.postgresql.org; Sat, 03 Jan 2026 00:58:42 +0000 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-37ba5af5951so115081211fa.1 for ; Fri, 02 Jan 2026 16:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeltef.nl; s=google; t=1767401917; x=1768006717; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qt5JVeA8v3HoobZ4EYhHCVakaBTY6gmi/yzrJUJcPkQ=; b=qOQ+lkGQmobpSXWybV4GuDni8WUtYmNBEtk13cVJckyhVCIK26sMtTc3fjih9WXnL4 /F5/C+T4N8zzcHx4hoeCzmBaSECfwerbdKV6m1QsI3xEXO/ZgL8XvyEY9yAZZG653E4L weROxh8iYQHbF5e5rMWiok/pY6KA3aicZ48p2IaW6M1ToNt1kpnfpwe5UNlenru3aN6H gzrNl7EclxZ96utg/astcgqneUX/LUbPZA5TYH/vBQYZGt6i2sDDsNGX7t2TPjL1sfXe pcZ1cvzmI9zxdnZvKqcWGK0SWUMWlRMt6cpUpOeCDOZPtKzUcc5B3aD+8Lt0xJg4z3GY iILw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767401917; x=1768006717; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qt5JVeA8v3HoobZ4EYhHCVakaBTY6gmi/yzrJUJcPkQ=; b=f10eVqjTmF5QDFUt4cLfSji/ciwxKgHV8pEvp8aoXwiGTE6W09Zxi1IhVmqIushcHh NrWw5sMMFVqkNDA4GRKPAMWmXN6hBCV9rBbS5ryfKhQd0nkcNd3kgnDFG7CimxIYrBa1 hcgolwnnkXM0ZSZdNqyD8Cmej57bq0pC77Z8ydcJKG6JEvM1JhMyMp+0nNUC1YsbLJgG jVhtRU2928fdB84vF3eschJBA29CKWVoiBXDC3kUUEBFm4CjOsGTWJQ5kbQ+Qs8jzZWy KCEvlMlOs0iHR7wwRH4M8UahPeEqoqG0HOaSccif9f6rMX/3t06ZKritt5WrVy2LQ4+A 2K1Q== X-Gm-Message-State: AOJu0YzwUa7ofH0YkWUKnGTEysTO1mglC6/753DA2GdNAywoFmRxUrwN 4M2RovtBZ1KiOpo6CMnpKLScOjXEKDzZKBMv8HvlgpEpaQEN3kSP9M9FMe/kfJTiD38J/YSTHGS S9AnP59PZ3JH4kP2/xoRgOU/DbF9QEZiKBqm4V4M2tg== X-Gm-Gg: AY/fxX5j+QlMf41OKdKF1bl1BUCp8LxhduD0STgudXn7Ysv2xGOWVMhTaySJwdgESld 69rQsFkEw2pekuWEAREngKx8ORA/N8DdOGxWWzH6XGq4+Mn58BgNp9CBwyPkzLHFMRWuTa7hQze LJ6wln+JrwzfUDiTkz/4WFzh9fvxKleTmBMkN4O/Iu/nvVcDbNahLUeIQITB4LybVBzCpR9/xG/ 3NAfbH1oFJqm1cDc4+jek/bu8xA9iXihsd8id+yzQtBjZS3yyf/jh5woCc6qqUNV285LHl4 X-Google-Smtp-Source: AGHT+IGjhL3G/ACHS/umjjAl+nVf0EozkwfXLdMckct/UFH7WhC+6LnVg7NZKq5AthvR3x2SPVZRHQummycfbZGdWMk= X-Received: by 2002:a05:651c:1469:b0:380:e85:97e7 with SMTP id 38308e7fff4ca-3812167c5ddmr108853821fa.37.1767401917039; Fri, 02 Jan 2026 16:58:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jelte Fennema-Nio Date: Sat, 3 Jan 2026 01:58:25 +0100 X-Gm-Features: AQt7F2qktqkP8P3vvHFeMCHilLKOmOz52y74AvO3RGD_rbopHXvMXOf30aH63cg Message-ID: Subject: Re: Parallelizing startup with many databases To: Babak Ghadiri Cc: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="0000000000007100db06477153cf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000007100db06477153cf Content-Type: text/plain; charset="UTF-8" On Fri, Jan 2, 2026, 08:55 Babak Ghadiri 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/11bc2bb7-ecb5-3ad0-b39f-df632734cd81@discourse.org 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 > --0000000000007100db06477153cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 2, 2026, 08:55 Babak Ghadiri <bbkg= hadiri6@gmail.com> wrote:
Hello,
I hope you are doing well.

In PostgreSQL 16= , startup appears to initialize databases sequentially and
primarily use= s 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 setti= ng:
recovery_init_sync_method=3Dsyncfs<= /div>

I'm 99% certain that= that will solve your problem.=C2=A0




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.=C2= =A0https://www.postgresql.org/docs/current/run= time-config-wal.html#RUNTIME-CONFIG-WAL-RECOVERY
<= div class=3D"gmail_quote">
<= /div>
--0000000000007100db06477153cf--