Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic
| От | Peter Geoghegan |
|---|---|
| Тема | Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic |
| Дата | |
| Msg-id | CAH2-Wz=ph4x6f3zWMaUYD=y5ujnR9ss0uzMADWYZoY2OJqC3pw@mail.gmail.com обсуждение исходный текст |
| Ответ на | 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 Tue, Jun 8, 2021 at 5:18 PM Justin Pryzby <pryzby@telsasoft.com> wrote: > I reproduced the issue on a new/fresh cluster like this: > > ./postgres -D data -c autovacuum_naptime=1 -c autovacuum_analyze_scale_factor=0.005 -c log_autovacuum_min_duration=-1 > psql -h /tmp postgres -c "CREATE TABLE t(i int); INSERT INTO t SELECT generate_series(1,99999); CREATE INDEX ON t(i);" > time while psql -h /tmp postgres -qc 'REINDEX (CONCURRENTLY) INDEX t_i_idx'; do :; done& > time while psql -h /tmp postgres -qc 'ANALYZE pg_attribute'; do :; done& I don't have time to try this out myself today, but offhand I'm pretty confident that this is sufficient to reproduce the underlying bug itself. And if that's true then I guess it can't have anything to do with the pg_upgrade/pg_resetwal issue Tom just referenced, despite the apparent similarity. Thanks -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: