Horton

Re: dsa_allocate() faliure

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Arne Roland <A.Roland@index.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-performance@lists.postgresql.org
Date: 2019-02-04T21:47:08Z
Lists: pgsql-hackers, pgsql-performance 
On Mon, Feb 04, 2019 at 08:31:47PM +0000, Arne Roland wrote:
> I could take a backup and restore the relevant tables on a throwaway system. You are just suggesting to replace line 728
> elog(FATAL,
>                                  "dsa_allocate could not find %zu free pages", npages);
> by
> elog(PANIC,
>                                  "dsa_allocate could not find %zu free pages", npages);
> correct? Just for my understanding: why would the shutdown of the whole instance create more helpful logging?

You'd also start with pg_ctl -c, which would allow it to dump core, which could
be inspected with GDB to show a backtrace and other internals, which up to now
nobody (including myself) has been able to provide.

Justin

Commits

  1. Fix rare dsa_allocate() failures due to freepage.c corruption.

  2. Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.

  3. Fix crashes on plans with multiple Gather (Merge) nodes.