Re: dsa_allocate() faliure
От | Fabio Isabettini |
---|---|
Тема | Re: dsa_allocate() faliure |
Дата | |
Msg-id | 9663C144-68A3-4BD1-89E9-9D97E180E750@voipfuture.com обсуждение исходный текст |
Ответ на | Re: dsa_allocate() faliure (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-performance |
Hi Thomas, it is a Production system and we don’t have permanent access to it. Also to have an auto_explain feature always on, is not an option in production. I will ask the customer to give us notice asap the error present itself to connect immediately and try to get a query plan. Regards Fabio Isabettini www.voipfuture.com > On 30. Jan 2019, at 04:13:14, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > > On Tue, Jan 29, 2019 at 10:32 PM Fabio Isabettini > <fisabettini@voipfuture.com> wrote: >> we are facing a similar issue on a Production system using a Postgresql 10.6: >> >> org.postgresql.util.PSQLException: ERROR: EXCEPTION on getstatistics ; ID: EXCEPTION on getstatistics_media ; ID: uidatareader. >> run_query_media(2): [a1] REMOTE FATAL: dsa_allocate could not find 7 free pages > >> We would like not to stop the Production system and upgrade it to PG11. And even though would this guarantee a permanentfix? >> Any suggestion? > > Hi Fabio, > > Thanks for your report. Could you please also show the query plan > that runs on the "remote" node (where the error occurred)? > > There is no indication that upgrading to PG11 would help here. It > seems we have an undiagnosed bug (in 10 and 11), and so far no one has > been able to reproduce it at will. I personally have chewed a lot of > CPU time on several machines trying various plan shapes and not seen > this or the possibly related symptom from bug #15585 even once. But > we have about three reports of each of the two symptoms. One reporter > wrote to me off-list to say that they'd seen #15585 twice, the second > time by running the same query in a tight loop for 8 hours, and then > not seen it again in the past 3 weeks. Clearly there is issue needing > a fix here, but I don't yet know what it is. > > -- > Thomas Munro > http://www.enterprisedb.com >
В списке pgsql-performance по дате отправления: