Re: Report oldest xmin source when autovacuum cannot remove tuples

From: Scott Ray <scott(at)scottray(dot)io>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Report oldest xmin source when autovacuum cannot remove tuples
Date: 2026-05-30 02:31:27
Message-ID: 3bnBUxwx2npXqvHL0trI11LOOvzQ7LI0GzWqbaj5SJnk7DTb1uzStGveKwj0JJmBW4ebzGIF3az7of4I4rQeaO_PRqDnnClCduPyjM6gPgM=@scottray.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I guess the overhead of one more scan of the process array for every autovacuum
> run if "log_autovacuum_min_duration" is non-zero (which is the default)
> is acceptable.

Could vacuum compute the blocker during ComputeXidHorizons and consume it at log time?
Avoids the extra scan, and binds the blocker to the horizon vacuum used for pruning.

Scott Ray

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-05-30 02:47:37 Re: Row pattern recognition
Previous Message Sami Imseih 2026-05-30 02:15:31 Re: Improve pg_stat_statements scalability