From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Sand Stone <sand(dot)m(dot)stone(at)gmail(dot)com> |
Cc: | Rick Otten <rottenwindfish(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: dsa_allocate() faliure |
Date: | 2018-10-05 02:16:41 |
Message-ID: | CAEepm=1k7sYJbxoOSJcS-4ti2MHOnBXBfLf=-gtuFLTXPqvTDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Wed, Aug 29, 2018 at 5:48 PM Sand Stone <sand(dot)m(dot)stone(at)gmail(dot)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 the worker 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 this node. The whole query finished just fine. So the parallel query plan is from one of the nodes not crashed, hopefully the same plan would have been executed on the crashed node. In theory, every worker node has the same bits, and very 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-10-05 02:24:56 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |
Previous Message | Tom Lane | 2018-10-05 02:12:04 | Re: Odd 9.4, 9.3 buildfarm failure on s390x |
From | Date | Subject | |
---|---|---|---|
Next Message | ROS Didier | 2018-10-06 09:57:25 | Why the index is not used ? |
Previous Message | Pavel Stehule | 2018-10-05 01:34:14 | Re: [HACKERS] proposal: schema variables |