A Qua, 13-07-2016 às 17:15 -0400, Tom Lane escreveu:
> Miguel Ramos <org.postgresql@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
No, no PostGIS here. The columns latitude, longitude and height are
just arrays. The first two are arrays of double and height is an array
of single. So, if anything, this could be related to array processing.
Thanks,
-- Miguel Ramos