RE: Vacuumdb on a table

Thanks.

I retried with -F. That actually worked and lowered the relfrozenxid of the table.

1) I am wondering if -F option interferes with application (table lock, row lock etc).
2) It says "aggressively vacuuming "<table>". Do you always see this with -F option? Is it harmless in terms of locking
select/insert/update/deletestatements from application?
 

vacuumdb -v -d <database> -t <table> -F

vacuumdb: vacuuming database "<database>"
INFO:  aggressively vacuuming "<table>"
INFO:  launched 1 parallel vacuum worker for index cleanup (planned: 1)
INFO:  table "<table>": found 0 removable, 172218350 nonremovable row versions in 6332166 out of 6332166 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 1465648214
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 134.15 s, system: 199.88 s, elapsed: 1856.67 s.
INFO:  aggressively vacuuming "pg_toast.pg_toast_<toastref>"
INFO:  table "pg_toast_<toastref>": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 1465693324
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.

Thanks.

-----Original Message-----
From: depesz@depesz.com <depesz@depesz.com> 
Sent: Thursday, October 19, 2023 3:27 AM
To: Murthy Nunna <mnunna@fnal.gov>
Cc: pgsql-admin@postgresql.org
Subject: Re: Vacuumdb on a table

On Wed, Oct 18, 2023 at 08:05:53PM +0000, Murthy Nunna wrote:
> Hi,
> 
> The first table in the following query resulted in age(c.relfrozenxid) 
> = 148795396. But when I manually run vacuumdb command (vacuumdb -d db1 
> -t tab1) on that table it is not lowering the relfrozenxid. There is 
> no indication in the pglog that vacuumdb failed.

Retry with vacuumdb -F

Best regards,

depesz