Yep, you called it: Nov 2 20:30:45 localhost kernel: Out of memory: Kill process 30438 (postmaster) score 709 or sacrifice child Nov 2 20:30:45 localhost kernel: Killed process 30438, UID 26, (postmaster) total-vm:3068900kB, anon-rss:1695392kB, file-rss:1074692kB
So it's running out of memory when trying to dump this table. The "old" server has 4GB of ram, the "new" server 20GB. On Sun, Nov 4, 2018 at 3:13 PM Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 11/4/18 8:38 AM, Charles Martin wrote: > > > > Adtrian said: > >>> pg_dump: Error message from server: server closed the connection > >>> unexpectedly > > > > >Is this error the client reporting? > > >Is this the same that is showing up in the server log? > > > > Yes, that's the client message, i.e. what appeared in the terminal > > window that gave the command. The server log shows: > > > > 2018-11-02 20:30:46 EDT [20405]: [4-1] user=,db= LOG: server process > > (PID 30438) was terminated by signal 9: Killed > > > > 2018-11-02 20:30:46 EDT [20405]: [5-1] user=,db= DETAIL: Failed process > > was running: COPY public.docfile (docfile_pkey, docfileoriginalname, > > ordernumber, versionnum, docfilecontents, docfilepath, d$ > > > > 2018-11-02 20:30:46 EDT [20405]: [6-1] user=,db= LOG: terminating any > > other active server processes > > > > 2018-11-02 20:30:46 EDT [20415]: [10-1] user=,db= WARNING: terminating > > connection because of crash of another server process > > > > 2018-11-02 20:30:46 EDT [20415]: [11-1] user=,db= DETAIL: The > > postmaster has commanded this server process to roll back the current > > transaction and exit, because another server process exited abnor$ > > > > > > > >>So where is the server located relative to the pg_dump client? > >>On the same machine? > >>If so is it a virtual machine e.g AWS? > >>Across a local or remote network? > > > > > > I gave the command in a terminal session after SSHing to the server > > from the same network. It is not a virtual machine. > > > > > > Lsaurenz said: > > > > > >>You probably have a corrupted database. > >>You should get that fixed first, then you can upgrade. > >>Maybe you should hire a professional for that. > > > > > > I suspect this is is correct, both that there is corruption in the table > > and that I need a professional to help. If someone here is available, > > I'm interested. > > Given that this involves your largest table I would confirm that the > signal 9 kill was not coming from the system OOM killer. Take a look at > the system logs to see what they show over the same time period. > > > > > > > Andreas said: > > > > > > >which exact minor version please? > > > > > > PostgreSQL 9.6.10 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 > > 20120313 (Red Hat 4.4.7-23), 64-bit > > > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
