Re: dsa_allocate() faliure

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: dsa_allocate() faliure
Дата
Msg-id CAEepm=1RA7OZPWZ0BOY4JUm5MxxXt4cN3Jq3Y82MmfgvBj4ghw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dsa_allocate() faliure  (Fabio Isabettini <fisabettini@voipfuture.com>)
Ответы Re: dsa_allocate() faliure  (Fabio Isabettini <fisabettini@voipfuture.com>)
Re: dsa_allocate() faliure  (Jakub Glapa <jakub.glapa@gmail.com>)
Список pgsql-performance
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How can sort performance be so different
Следующее
От: Saurabh Nanda
Дата:
Сообщение: Re: Will higher shared_buffers improve tpcb-like benchmarks?