Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
Дата
Msg-id 202106081801.k2v2scnopsqb@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On 2021-Jun-08, Justin Pryzby wrote:

> On Tue, Jun 08, 2021 at 12:06:02PM -0400, Alvaro Herrera wrote:
> > On 2021-Jun-06, Justin Pryzby wrote:
> > 
> > > However, I also found an autovacuum chewing 100% CPU, and it appears the
> > > problem is actually because autovacuum has locked a page of pg-statistic, and
> > > every other process then gets stuck waiting in the planner.  I checked a few
> > > and found these:
> > 
> > Hmm ... I wonder if this could be related to commits d9d076222f5b,
> > c98763bf51bf, etc.  I don't have any connecting thoughts other than the
> > tuple visibility code being involved.  Do you see any procs with the
> > PROC_IN_SAFE_IC flag set?
> 
> Can you give me a hint how to do that from a corefile ?

(gdb) set $i=0
(gdb) set $total = ProcGlobal->allProcCount
(gdb) while($i<$total)
 >print ProcGlobal->allProcs[$i++]->statusFlags
 >end

-- 
Álvaro Herrera       Valdivia, Chile
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle."  (Larry Wall, Apocalypse 6)



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: automatically generating node support functions
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Fdw batch insert error out when set batch_size > 65535