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 1vlBIO-008S7l-1c for pgsql-admin@arkaria.postgresql.org; Wed, 28 Jan 2026 19:33: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 1vlBIN-003DSI-0m for pgsql-admin@arkaria.postgresql.org; Wed, 28 Jan 2026 19:33:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vlBIM-003DS2-2T for pgsql-admin@lists.postgresql.org; Wed, 28 Jan 2026 19:33:43 +0000 Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vlBIJ-002n2R-2V for pgsql-admin@postgresql.org; Wed, 28 Jan 2026 19:33:42 +0000 Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-82318b640beso117472b3a.0 for ; Wed, 28 Jan 2026 11:33:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769628820; cv=none; d=google.com; s=arc-20240605; b=KW1TaeHUNomgn3TfORqLnaL39OE0yBZ7evFnWM07iUMejKp5oS0eFVzP1S8Si7yX8O y88AI0SYtfELD7F/gbB2NhJtS4Gjj4e/d5PAJ4KKTV817/h0pIyXCpLRazz3qtSC2t2N h+2Oa7wg8GgaDSJ015kMromG6xanzWhhZh+fAnaTjEvDV6cikPIL9Ng/7KTqbJFYCHiH vo0vkswWsSQTRKDPqED4rsBBPq1TkmByXX+ek9C8wpbSMQSOQtYi8u/gqYfPk89X+3VF z1+YzCudGD3+vBcR92O/Ow/2U1+IU/876nDM1dfS75v5qClFVB1JJRgaEA+1epQn5xTY rabg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=fVu21vurngGbsH5cY3hCYkyXCWh1HWOoj+xeuN5/2nk=; fh=/nUPltZn1+UWflOv4Gxp+qqP/cnrMSrIla51Zo9rJPc=; b=Qmi+ZhksfqdJIX/a7oM82PnOdeSsebQ0mKKk7miw9ePFg4GXLWolDkxpdOJxvZCNae TOUQ89YAeJyVspT5aBFdIRJQjHroxNf3f4K+UqctQnXqgeLTe5rYowqCKVfmZzA2z39g qthEmNHFJzjT9xXbMney3TqQ1jHqrGAeSnDllIwj7Xz5ImkMnV08cqIXX+AbMw50B/eL aG+4jCbS4HO6qv95kBPJC2ZBWDM/9uTvLnhRlauEx4xgpDH9vr4CpYkFUTpfHWvIJkpf ELqjapEoqWEfAnyOGwfPubdMqAYKQaNgAN+WHkVZQZBAunocPabhVghT0vux/jBCyMk3 bghg==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769628820; x=1770233620; darn=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=fVu21vurngGbsH5cY3hCYkyXCWh1HWOoj+xeuN5/2nk=; b=XTb6PYkLX22HxzTgLHr9DhEYdtfR1hlz9WNZQVtLiI2FUIaXy1d+Th0f6G7XirYSjr 5vpUDfWJ1LHloZV4b+oPF4qB3AD9Wk0Vmz2zGKQrYJnh6+88A2CAIA+mUqzPTgyzuOVi PSHV5VMVU5Cr9ueo41b27q5qjmtotiHeFD8ldPchnyxKax8rhVoIC/kVB5ZxFVlIgOxM wr0r+4C7b+MjIPKJsTVVtrxHJAHsLhjUpcor/1TQIGSgC6McVaQpi4DlIWfxrM9I9Z4E L0bI5ZXQe8Y2hANQevimBujUB/TJ4tGccol3YlLFsjIRf5+NlgVZnfvJd2/YDv+JyXgh 8ybQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769628820; x=1770233620; 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=fVu21vurngGbsH5cY3hCYkyXCWh1HWOoj+xeuN5/2nk=; b=wylq6o5BJv5333tq++3Ry4VhCeQlvkseIShKDTkchZa1Fs/Ogy9WE7fClRTjP336ep bopqmRkUndhQ/N5hl2b8EXVwv4NvHzIaUBbrHwaG0hHldtwxA9NKl2kOxYq0s/IkWAua ULnjEyGVFNnZu92Rn3Gle8AGcEPyZ5efxK1N87o4mHWZeFzkoSS9M/ZbMMTYYT/rocpT 1orcOL4EkE29IFfDtc9f0XE/Kq0VbPN9epANo59Qw5aycV6DSnLj5G+E5ZJIt8gbrNj1 etTuCqgnMHMV2uflVKjxrq/WEy9BgFQdgOMiw+Q1n/HcWzwX1/XKEEEkbYNZCDqOibwc F/CA== X-Gm-Message-State: AOJu0YwR0zy5pqlHr+7dkoRNJvxVc8p0TADnwBZBIrnS+okWCOTkCiWS k2P+YwgkfPSg0hs8UQd0WCnyZkTCnOBHr6mwXZ2lHlGkr/oOBXoZyHOBPqH/H4Kvbc5zNLVOjaE 5yy8twQlQn10O3IwvUo1ZDwYqgwyCCMI= X-Gm-Gg: AZuq6aJGlRQr51/i4Cbuc39xXZC+z9eTJYmePSV8twx7PJPYjNqwhl5FY03IQ6wHnOh or74Pz/E+31YLxAGuvojf5tSz3V1iH7J09JXip9ZBV4Vju1TMmAA/r0KVegqBTw4jdeZHELUQkn 6pIJ0OeNuisFdTcDcjz97u62YZSZncGcgmM56RUCsFcOFyBHOlYdtpmGMKcESGYAPNfjlDsyLzK l1DJJ9tZcFn2Gt3AD7PcH3fX1XmMxhyY5VTCY2IcBvWc/sMf8UUbkpjvMfoPdtl8K6e8XkF X-Received: by 2002:a17:90b:2d83:b0:34e:5aa2:cf68 with SMTP id 98e67ed59e1d1-353fed8a891mr5037329a91.30.1769628819473; Wed, 28 Jan 2026 11:33:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 28 Jan 2026 14:33:27 -0500 X-Gm-Features: AZwV_QhaUP7ne-U14AT_oSaOS528wFDXw4ydHipaK9SZhzEdlZmYYHxCvdM3pcc Message-ID: Subject: Re: Restoration process generates 1.2 TB of WAL files. To: Wasim Devale Cc: pgsql-admin , Pgsql-admin Content-Type: multipart/alternative; boundary="0000000000002b4a86064977d1e7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002b4a86064977d1e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2026 at 2:16=E2=80=AFPM Wasim Devale w= rote: > Hi All > > I am taking directory dump from postgresql 12 and restoring it on > postgresql 17 this process create 1.2TB of wals files in pg_wal directory= . > Can we reduce this WAL files generation via any configuration changes? > Sure. This is what I used when restoring some 3+ TB databases. (Your values for $SharedBuffs and $MaintMem will vary based on how much RAM you have and how many threads you use in pg_restore.) Setting $SharedBuffs and (especially) $MaintMem too high will cause the Linux oom-killer to kill one or more of the CREATE INDEX or ADD PRIMARY KEY statements, and you'll scratch your head looking at the pg_restore log file wondering what happened. I based it on: https://www.databasesoup.com/2014/09/settings-for-fast-pgrestore.html pg_ctl restart -wt$TimeOut -mfast \ -o "-c hba_file=3D$PGDATA/pg_hba_maintmode.conf" \ -o "-c fsync=3Doff" \ -o "-c log_statement=3Dnone" \ -o "-c log_temp_files=3D100kB" \ -o "-c log_checkpoints=3Don" \ -o "-c log_min_duration_statement=3D120000" \ -o "-c shared_buffers=3D${SharedBuffs}GB" \ -o "-c maintenance_work_mem=3D${MaintMem}GB" \ -o "-c synchronous_commit=3Doff" \ -o "-c archive_mode=3Doff" \ -o "-c full_page_writes=3Doff" \ -o "-c checkpoint_timeout=3D30min" \ -o "-c max_wal_size=3D36GB" \ -o "-c wal_level=3Dminimal" \ -o "-c max_wal_senders=3D0" \ -o "-c wal_buffers=3D64MB" \ -o "-c autovacuum=3Doff" || exit $? pg_restore --verbose --jobs=3DX ... &> pg_restore.log || exit $? pg_ctl stop -wt9999 && pg_ctl start -wt9999 These are "bad" settings if you have other databases in your instance and they need to keep running while you restore your DB. *I don't have that * *problem*, so think it's great. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000002b4a86064977d1e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 28, 2026 at 2:16=E2=80=AFPM W= asim Devale <wasimd60@gmail.com> wrote:
Hi All

I am taking directory dump from postg= resql 12 and restoring it on postgresql 17 this process create 1.2TB of wal= s files in pg_wal directory. Can we reduce this WAL files generation via an= y configuration changes?

Sure.= =C2=A0 This is what I used when restoring some 3+ TB databases.=C2=A0 (Your= values for $SharedBuffs and $MaintMem will vary based on how much RAM you= =C2=A0have and how many threads you use in pg_restore.)

Setting $SharedBuffs and (especially) $MaintMem too high will cause t= he Linux=C2=A0oom-killer to kill one or more of the CREATE INDEX or ADD PRI= MARY KEY statements, and you'll scratch your head looking at the pg_res= tore log file wondering what happened.

I based it = on:

pg_ct= l restart -wt$TimeOut -mfast \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o "-c h= ba_file=3D$PGDATA/pg_hba_maintmode.conf" \
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 -o "-c fsync=3Doff" \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o "= ;-c log_statement=3Dnone" \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o "-c= log_temp_files=3D100kB" \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o "-c = log_checkpoints=3Don" \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o "-c log= _min_duration_statement=3D120000" \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -o = "-c shared_buffers=3D${SharedBuffs}GB" \
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 -o "-c maintenance_work_mem=3D${MaintMem}GB" \
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 -o "-c synchronous_commit=3Doff" \
=C2=A0= =C2=A0 =C2=A0 =C2=A0 -o "-c archive_mode=3Doff" \
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 -o "-c full_page_writes=3Doff" \
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 -o "-c checkpoint_timeout=3D30min" \
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 -o "-c max_wal_size=3D36GB" \
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 -o "-c wal_level=3Dminimal" \
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 -o "-c max_wal_senders=3D0" \
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 -o "-c wal_buffers=3D64MB" \
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 -o "-c autovacuum=3Doff"
=C2=A0|| exit $?
pg_restore --verbose --jobs=3DX ...= &> pg_restore.log || exit $?
pg_ctl stop -wt9999 && pg_ctl start -wt9999
These are "bad" settings if you have=C2=A0other data= bases in your instance and they need to keep running while you restore your= DB.=C2=A0 I don't have that problem, so think=C2=A0it= 9;s great.

--
= Death to <Redacted>, and butter sauce.
Don't boil me, I'm= still alive.
<Redacted> lobster!
--0000000000002b4a86064977d1e7--