Date: Tue, 27 Oct 2020 13:04:35 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
	"pgsql-admin@lists.postgresql.org" <pgsql-admin@lists.postgresql.org>
Subject: Re: free(): invalid pointer , when to dumping data to a new server
Message-ID: <20201027160435.GA15157@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <PR3P189MB1035C3DC4C526A813501E7FD9D160@PR3P189MB1035.EURP189.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Oct-27, Lars Aksel Opsahl wrote:

> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/pgsql-12/bin/postmaster...Reading symbols from /usr/lib/debug/usr/pgsql-12/bin/postgres-12.4-1PGDG.rhel8.x86_64.debug...done.
> done.
> BFD: warning: /var/lib/systemd/coredump/core.postmaster.26.6f7d98107f544085a41c6f8b876418d0.298120.1603810048000000 is truncated: expected core file size >= 2326896640, found: 2147483648
> 
> warning: core file may not match specified executable file.

Uh :-(  The core file would have been too large, so the system wrote a
truncated copy, with the result that GDB cannot interpret it correctly.

I don't know if you can raise the 2TB limit on core files, but one thing
you can do is change the "core filter" so that it doesn't dump shared
memory, which is often where the bloat comes from.  This will result in
a much smaller core file, but still useful to find the problem.  You can
do this:

echo 0x01 > /proc/$pid/coredump_filter
where the PID can be the postmaster's, before running pg_dump.