Re: dsa_allocate() faliure

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: dsa_allocate() faliure
Дата
Msg-id CAEepm=1k7sYJbxoOSJcS-4ti2MHOnBXBfLf=-gtuFLTXPqvTDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dsa_allocate() faliure  (Sand Stone <sand.m.stone@gmail.com>)
Ответы RE: dsa_allocate() faliure  (Arne Roland <A.Roland@index.de>)
Список pgsql-performance
On Wed, Aug 29, 2018 at 5:48 PM Sand Stone <sand.m.stone@gmail.com> wrote:
> I attached a query (and its query plan) that caused the crash: "dsa_allocate could not find 13 free pages" on one of
theworker nodes. I anonymised the query text a bit.  Interestingly, this time only one (same one) of the nodes is
crashing.Since this is a production environment, I cannot get the stack trace. Once turned off parallel execution for
thisnode. The whole query finished just fine. So the parallel query plan is from one of the nodes not crashed,
hopefullythe same plan would have been executed on the crashed node. In theory, every worker node has the same bits,
andvery similar data. 

I wonder if this was a different symptom of the problem fixed here:

https://www.postgresql.org/message-id/flat/194c0706-c65b-7d81-ab32-2c248c3e2344%402ndquadrant.com

Can you still reproduce it on current master, REL_11_STABLE or REL_10_STABLE?

--
Thomas Munro
http://www.enterprisedb.com


В списке pgsql-performance по дате отправления:

Предыдущее
От: Fabio Pardi
Дата:
Сообщение: Re: Why could different data in a table be processed with differentperformance?
Следующее
От: James Coleman
Дата:
Сообщение: Re: Partial index plan/cardinality costing