Miguel Ramos <org.postgre...@miguel.ramos.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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
