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.
The dump contains over 200M rows for that table and is in custom format,
which co
Em qui., 3 de mar. de 2022 às 05:59, Marc Rechté escreveu:
> 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.
> The dump co
Em qui., 3 de mar. de 2022 às 05:59, Marc Rechté escreveu:
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.
Em qui., 3 de mar. de 2022 às 09:19, Marc Rechté escreveu:
> Em qui., 3 de mar. de 2022 às 05:59, Marc Rechté
> escreveu:
> >
> > Hello,
> >
> > We have a pg_restore which fails due to RAM over-consumption of
> > the corresponding PG backend, which ends-up with OOM killer.
> >
> >
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 sch
> -Original Message-
> From: Justin Pryzby
> Sent: Tuesday, March 1, 2022 14:27
> To: l...@laurent-hasson.com
> Cc: pgsql-performa...@postgresql.org
> Subject: Re: An I/O error occurred while sending to the backend (PG 13.4)
>
> On Tue, Mar 01, 2022 at 04
=?UTF-8?Q?Marc_Recht=c3=a9?= writes:
> 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.
> The dump contains over 200M rows for that tab
Em qui., 3 de mar. de 2022 às 11:55, l...@laurent-hasson.com <
l...@laurent-hasson.com> escreveu:
>
>
>> -Original Message-
>> From: Justin Pryzby
>> Sent: Tuesday, March 1, 2022 14:27
>> To: l...@laurent-hasson.com
>> Cc: pgsql-performa...@postgresql.org
>>
On Thu, Mar 03, 2022 at 01:33:08PM -0300, Ranier Vilela wrote:
> Sorry, but this is much more on the client side.
The client is reporting the problem, as is the server.
> Following the logs, it is understood that the client is dropping the
> connection.
The logs show that the client's connection
Em qui., 3 de mar. de 2022 às 13:46, Justin Pryzby
escreveu:
> On Thu, Mar 03, 2022 at 01:33:08PM -0300, Ranier Vilela wrote:
> > Sorry, but this is much more on the client side.
>
> The client is reporting the problem, as is the server.
>
Are you read the server log?
" 2022-03-03 01:04:40 EST [
I am also starting to feel that the issue being on the database’s side is less
and less likely. There is something happening in between, or possibly on the
client.
Ranier, the only reason I was focusing on this at the PG level is that this
issue started to show up several months ago shortly aft
Em qui., 3 de mar. de 2022 às 15:19, l...@laurent-hasson.com <
l...@laurent-hasson.com> escreveu:
> I am also starting to feel that the issue being on the database’s side is
> less and less likely. There is something happening in between, or possibly
> on the client.
>
>
>
> Ranier, the only reaso
Le 03/03/2022 à 16:31, Tom Lane a écrit :
=?UTF-8?Q?Marc_Recht=c3=a9?= writes:
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.
The dump con
=?UTF-8?Q?Marc_Recht=c3=a9?= writes:
> Le 03/03/2022 à 16:31, Tom Lane a écrit :
>> Does memory consumption hold steady if you drop the FK constraints?
> Actually the number of rows is 232735712.
> Accordingly the RAM consumption would be x12 x3 = 7.8 GiB.
> This is close to the 8,1g I reported e
14 matches
Mail list logo
