Date: Mon, 4 Feb 2019 15:47:08 -0600
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
Subject: Re: dsa_allocate() faliure
Message-ID: <20190204214708.GI29720@telsasoft.com>
References: 
 <CAMAYy4+w3NTBM5JLWFi8twhWK4=k_5L4nV5+bYDSPu8r4b97Zg@mail.gmail.com>
 <CAEepm=2aHnTfPJnPbeS3AxO-ENoUg5-akuD-7PWYbn8+-c9JmQ@mail.gmail.com>
 <d9c6cc80e21241349db53b2f64075029@index.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d9c6cc80e21241349db53b2f64075029@index.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk

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