Re: BUG #17399: Dead tuple number stats not updated on long running queries

From: Soni M <diptatapa(at)gmail(dot)com>
To: diptatapa(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17399: Dead tuple number stats not updated on long running queries
Date: 2022-02-09 03:58:13
Message-ID: CAAMgDXmeqnoK7XkzhLkYDzTULH_NSN5+8eCTanh6Yn_HqtHkyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Some Update
After several times repeatedly autovacuum is launched on the table,
then it stops. After the long running queries finished, the postgres
service restarted, analyzed the table, the n_dead_tup still the same, then
vacuum again, but now the vacuum process detects again the dead row it has
cleaned previously.

It seems the concurrency control in the vacuum process.

On Tue, Feb 8, 2022 at 8:41 AM PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 17399
> Logged by: Soni
> Email address: diptatapa(at)gmail(dot)com
> PostgreSQL version: 13.5
> Operating system: Red Hat Enterprise Linux release 8.5 (Ootpa)
> Description:
>
> Hello All,
> I think I found a bug.
>
> While there are long running queries, a vacuum that start and end during
> the
> long running queries, the stats of pg_stat_user_tables.n_dead_tup not
> updated. The real dead tuple on the table is cleaned up, but not the
> stats.
> So, if dead tuple percentage on pg_stat_user_tables is above
> autovacuum_vacuum_scale_factor, then the autovacuum keeps triggered during
> the long running queries.
>
>

--
Regards,

Soni Maula Harriz

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Ben Chobot 2022-02-09 04:28:39 Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
Previous Message Michael Paquier 2022-02-09 01:35:57 Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica