Re: free(): invalid pointer , when to dumping data to a new server

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: free(): invalid pointer , when to dumping data to a new server
Date: 2020-10-27 16:04:35
Message-ID: 20201027160435.GA15157@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2020-10-27 16:04:59 Re: free(): invalid pointer , when to dumping data to a new server
Previous Message Lars Aksel Opsahl 2020-10-27 15:15:10 Re: free(): invalid pointer , when to dumping data to a new server