Date: Thu, 3 Mar 2022 08:46:13 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Marc =?iso-8859-1?Q?Recht=E9?= <marc4@rechte.fr>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: OOM killer while pg_restore
Message-ID: <20220303144613.GF27651@telsasoft.com>
References: <866ba95f-86fb-fa9b-ecee-65281160cff9@rechte.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <866ba95f-86fb-fa9b-ecee-65281160cff9@rechte.fr>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220303144613.GF27651%40telsasoft.com>
Precedence: bulk

On Thu, Mar 03, 2022 at 09:59:03AM +0100, Marc Rechté wrote:
> Hello,
> 
> We have a pg_restore which fails due to RAM over-consumption of the
> corresponding PG backend, which ends-up with OOM killer.
> 
> The table has one PK, one index, and 3 FK constraints, active while restoring.

Send the schema for the table, index, and constraints (\d in psql).

What are the server settings ?
https://wiki.postgresql.org/wiki/Server_Configuration

What OS/version ?

> The dump contains over 200M rows for that table and is in custom format,
> which corresponds to 37 GB of total relation size in the original DB.
> 
> While importing, one can see the RSS + swap increasing linearly for the
> backend (executing the COPY)
> 
> On my machine (quite old PC), it failed after 16 hours, while the disk usage
> was reaching 26 GB and memory usage was 9.1g (RSS+swap)