Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
В списке pgsql-hackers по дате отправления:
| От | Alvaro Herrera |
|---|---|
| Тема | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Дата | |
| Msg-id | 202106081606.2ve4tjdepsge@alvherre.pgsql обсуждение |
| Ответ на | 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-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? -- Álvaro Herrera 39°49'30"S 73°17'W
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера