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
|
Список | 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 по дате отправления: