Re: dsa_allocate() faliure

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: dsa_allocate() faliure
Дата
Msg-id 20190210165007.GT31721@telsasoft.com
обсуждение исходный текст
Ответ на Re: dsa_allocate() faliure  (Sergei Kornilov <sk@zsrv.org>)
Список pgsql-hackers
On Sun, Feb 10, 2019 at 07:11:22PM +0300, Sergei Kornilov wrote:
> > I ran overnight with this patch, but all parallel processes ended up stuck in
> > the style of bug#15585. So that's either not the root cause, or there's a 2nd
> > issue.
> 
> Maybe i missed something in this discussion, but you can reproduce bug#15585? How? With this testcase:
https://www.postgresql.org/message-id/CAEepm%3D1MvOE-Sfv1chudx5KEmw_qHYrj8F9Og_WmdBRhXSQ%2B%2Bw%40mail.gmail.com?
 

By running the queued_alters query multiple times in a loop:
https://www.postgresql.org/message-id/20181231221734.GB25379%40telsasoft.com

I'm able to trigger dsa "ERROR"s with that query on a newly initdb cluster with
only that table.  But I think some servers are more likely to hit it than
others.

I've only tripped on 15585 twice, and only while trying to trigger other DSA
bugs (the working hypothesis is that bug is 2ndary issue which happens after
hitting some other bug).  And not consistently or quickly.

Justin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)