Re: pg_restore out of memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Miguel Ramos <mail(at)miguel(dot)ramos(dot)name>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_restore out of memory
Date: 2016-07-15 13:13:32
Message-ID: 22561.1468588412@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Miguel Ramos <mail(at)miguel(dot)ramos(dot)name> writes:
> I see (transcribed by hand from screenshot):
> ...
> pg_restore: processing data for table "inspection.positioned_scan"
> out of memory

> Process returned exit code 1.

Right, so that confirms that the OOM happens while sending data for that
table; but we're still no closer as to why.

> I hadn't yet set log_min_messages to 'notice'. But as client_min_messages is at 'notice', aren't this displayed on a verbose pg_restore?

The theory I'd been considering was that NOTICE messages were being sent
by the server during the COPY (and not logged in the postmaster log
because log_min_messages wasn't high enough), but for some reason they
were not immediately processed and printed by pg_restore. In such a case
they'd accumulate in libpq's input buffer. After enough such messages
you'd eventually get an OOM failure. Now the big hole in this theory is
that it's unclear why the server would be sending any notices. But I
can't think of other good ideas.

> Now I'm repeating the backup (maybe the file is bad) and then I will repeat the restore with log_min_messages to 'notice'.

OK.

> I suppose log_statement to 'all' is no longer necessary?

I agree; we already know which statement is failing.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Willy-Bas Loos 2016-07-15 13:46:45 migrating data from an old postgres version
Previous Message Kaixi Luo 2016-07-15 11:38:33 Re: Slow query on primary server runs fast on hot standby