=?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
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
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
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 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 [
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 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
>>
=?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
> -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
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
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.
> >
> >
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 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
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
14 matches
Mail list logo
