Re: pg_restore out of memory

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

Miguel Ramos <org(dot)postgresql(at)miguel(dot)ramos(dot)name> writes:
> So, what does this mean?
> Was it the client that aborted? I think I saw that "unexpected message
> type 0x58" on other types of interruptions.

Yeah, 0x58 is ASCII 'X' which is a Terminate message. Between that and
the unexpected-EOF report, it's quite clear that the client side went
belly-up, not the server. We still don't know exactly why, but given
that pg_restore reports "out of memory" before quitting, there must be
some kind of memory leak going on inside pg_restore.

> Jul 13 20:10:10 ema postgres[97889]: [867-1] LOG: statement: COPY positioned_scan (id_dataset, id_acquired_set, sequence_number, id_scan_dataset, latitude, longitude, height, srid, srid_vertical) FROM stdin;

I'm guessing from the column names that you've got some PostGIS data
types in this table. I wonder if that's a contributing factor.

I'm still suspicious that this might be some sort of NOTICE-processing-
related buffer bloat. Could you try loading the data with the server's
log_min_messages level cranked down to NOTICE, so you can see from the
postmaster log whether any NOTICEs are being issued to the pg_restore
session?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2016-07-13 21:19:46 Re: pg_restore out of memory
Previous Message Adrian Klaver 2016-07-13 21:15:11 Re: pg_restore out of memory