A Qua, 13-07-2016 às 18:42 -0400, Tom Lane escreveu:
> I wrote:
> > 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?
>
> BTW, I experimented with that theory by creating a table with a
> BEFORE
> INSERT trigger function that emits a NOTICE, and then making
> pg_restore
> restore a lot of data into it. I could not see any memory growth in
> the pg_restore process. However, I was testing 9.1.22, not 9.1.8.
> Also, some of the misbehaviors we've discovered along these lines
> have
> been timing-sensitive, meaning that the problem might or might not
> reproduce for another person even with the same software version.
> Are you running pg_restore locally on the same machine as the server,
> or across a network --- and if the latter, how fast is the network?
>
> regards, tom lane
>
I was running pg_restore locally.
The disk containing the backup, however, is on NAS.
The NAS is mounted on the server using SMB and the FreeBSD kernel
implementation of smbfs (mount_smbfs -I ... /mnt).
The kernel smbfs is notoriously outdated and sometimes we get timeouts.
However, those timeouts happen randomly and this "out of memory"
happens consistently.
This time, the server was no longer under heavy load, the log lines are
consecutive, there was no activity during the start of the COPY
statement and the error.
The network is 1Gbps with a single unmanaged 24-port switch.
The server
has two aggregated links to the switch.
I ran pg_restore locally because the server is in another office, connected to mine through a VPN.
Now I have arranjed for a PC to be there for me and my next test will be to do the restore using the latest pgadmin.
Thanks,
-- Miguel Ramos