Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gzPWK-0008Mv-JY for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Feb 2019 17:30:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gzPWJ-0000C7-DC for pgsql-bugs@arkaria.postgresql.org; Thu, 28 Feb 2019 17:30:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gzPWJ-0008K1-2Y for pgsql-bugs@lists.postgresql.org; Thu, 28 Feb 2019 17:30:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gzPWG-00087D-Ay for pgsql-bugs@lists.postgresql.org; Thu, 28 Feb 2019 17:30:53 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1SHUmo0011677; Thu, 28 Feb 2019 12:30:48 -0500 From: Tom Lane To: Haribabu Kommi cc: iserbin@bostonsd.ru, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15660: pg_dump memory leaks when dumping LOBs In-reply-to: References: <15660-db101adab620a17a@postgresql.org> Comments: In-reply-to Haribabu Kommi message dated "Thu, 28 Feb 2019 19:00:12 +1100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11675.1551375048.1@sss.pgh.pa.us> Date: Thu, 28 Feb 2019 12:30:48 -0500 Message-ID: <11676.1551375048@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Haribabu Kommi writes: > On Wed, Feb 27, 2019 at 10:58 PM PG Bug reporting form < > noreply@postgresql.org> wrote: >> One of our customers faced an unexpected behaviour when using pg_dump to >> export one of DBs - pg_dump consumed all the server memory and got >> terminated with following error: > pg_dump process collects all the database objects first (tables, indexes > and etc) and then it write them into the file/archive. > In your scenario, there are many large objects that are present which leads > to allocate memory for the each object before it gets dumped leads to out of > memory. Yeah. We've heard about this repeatedly since large objects were promoted to be full-fledged objects with individual owners and ACL info. It was argued at the time that large objects would be, well, large, and therefore there wouldn't be *that* many of them, and so it'd be okay for pg_dump to treat them as full-fledged objects with their own dump-table-of-contents entries. Evidently, not everybody uses them that way :-(. At some point I think we're going to have to revisit that decision in pg_dump. Maybe we could merge things so that we have one TOC entry for all blobs that share the same owner and ACL? But it comes up seldom enough that nobody's gotten motivated to do the work. In the short run, the only answer is to run pg_dump on beefier iron, or else split up the dump as Haribabu suggests (although TBH I'm afraid that might not work either --- if memory serves, pg_dump tends to pull in all the per-object info even if it's not going to dump it all ...) regards, tom lane