Message-ID: <44c1b3003bced2e9eac55184666d22502e97de4d.camel@cybertec.at>
Subject: Re: RDS restore failed due to WAL log and disk space-- any tidy
 fixes?
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Wells Oliver <wells.oliver@gmail.com>
Cc: pgsql-admin <pgsql-admin@postgresql.org>
Date: Sun, 17 Nov 2024 19:18:58 +0100
In-Reply-To: 
 <CAOC+FBX1L6hx4DHzH34eaWyhH6NK9ywYSJMMcEJH3rHZfW86+A@mail.gmail.com>
References: 
	<CAOC+FBVyTiuOMF92pQG3QOrE9j8qFegvZLoi-3UmdhFNg94e2A@mail.gmail.com>
	 <14770c231bf27ea6d22376395ac8f02e41462ed5.camel@cybertec.at>
	 <CAOC+FBX1L6hx4DHzH34eaWyhH6NK9ywYSJMMcEJH3rHZfW86+A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.4 (3.52.4-2.fc40) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/44c1b3003bced2e9eac55184666d22502e97de4d.camel%40cybertec.at>
Precedence: bulk

On Sun, 2024-11-17 at 09:12 -0800, Wells Oliver wrote:
> On Sun, Nov 17, 2024 at 7:41=E2=80=AFAM Laurenz Albe <laurenz.albe@cybert=
ec.at> wrote:
> > On Sat, 2024-11-16 at 16:33 -0800, Wells Oliver wrote:
> > > I provisioned an RDS instance with 2500GB space and began the restore=
 of a database I know to be about 1750 GB using 16 jobs.
> > >=20
> > > Unfortunately, it died very near the end when it ran out of disk spac=
e due to WAL log usage. Lots of:
> > >=20
> > > 2024-11-17 00:07:09 UTC::@:[19861]:PANIC:=C2=A0 could not write to fi=
le "pg_wal/xlogtemp.19861": No space left on device
> > >=20
> > >=20
> > > And then kaboom.
> > >=20
> > > I'm wondering what my course of action should be. Can I disable/reduc=
e WAL during a restore?
> > > wal_level is set to replica, can this temporarily be set to minimal? =
Should I just eat the extra
> > > costs to add headroom for the WAL? Would using fewer jobs during a re=
store reduce the amount of WAL
> > > created?
> >=20
> > If you are using minimal WAL logging and you restore the dump in a sing=
le transaction, you
> > should see way less WAL generated, because data inserted into the table=
 in the same transaction
> > as the CREATE TABLE statement need not be WAL logged.
> >=20
> > But you might more easily solve the problem by speeding up or disabling=
 the WAL archiver,
> > so that PostgreSQL removes old WAL after the next checkpoint.
>
> Interesting. I am migrating a pg_dump archive to a new server, in a singl=
e go. Does it make sense
> to disable (or speed up?) WAL archiving during the restore, then reenable=
 it after the restore so
> a future replica could work? What would be the steps here? Would disablin=
g or "speeding up" be faster?

Ah, I ignored that you were using a hosted database.  Then you probably can=
not configure WAL archiving.

Yours,
Laurenz Albe