Miguel Ramos <org.postgresql@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
