vacuum full
Just keeping it in a separate email, incase this is thrashed down.
vacuum full has a lot of problem stories, not just because the db gets
locked, but also because it is mostly (mis)used when there are space issues.
of course, there are strong warnings in docs and wiki about using a vacuum
full,
but i was just thinking
vacuumdb and vacuumlo can make use of options like --dry-run, like
pg_repack allows,
but also just abort incase there is no disk space available.
i mean, i have seen confident replies from earlier mailing threads, where
assume 2x disk required per object that is full vacuumed at least.
can this be converted into an estimate of sorts on objects that would be
vacuumed and free disk that would be required before any operation starts.
maybe this is wishful thinking, but just asking.
--
Thanks,
Vijay
Mumbai, India
On Mon, 30 Aug 2021 at 23:12, Vijaykumar Jain <
vijaykumarjain.github@gmail.com> wrote:
Just keeping it in a separate email, incase this is thrashed down.
vacuum full has a lot of problem stories, not just because the db gets
locked, but also because it is mostly (mis)used when there are space issues.
ok ignore.
I think querying the disk for available space may be shell access from the
client, a security issue.
Also, a 10GB table with all dead tuples is 100% bloat, and would not really
need additional space for table rebuilds.
I think we can just put out some queries like bloat estimation of
relations, to get an idea of wasted space and used space
and estimate based on that on how much would be taken up from the disk
before being cleaned up.
ref queries: PostgresQL Automating VACUUM FULL for bloated tables - Stack
Overflow
<https://stackoverflow.com/questions/13931989/postgresql-automating-vacuum-full-for-bloated-tables>
--
Thanks,
Vijay
Mumbai, India
Morning.
Thanks for all the replies.
What I did to remove these files was to backup of the DB, drop the DB and then I restored the DB.
Regards
Ian
From: Vijaykumar Jain <vijaykumarjain.github@gmail.com>
Sent: Monday, 30 August 2021 20:06
To: pgsql-general <pgsql-general@lists.postgresql.org>
Subject: Re: vacuum full
External email - treat with caution
On Mon, 30 Aug 2021 at 23:12, Vijaykumar Jain <vijaykumarjain.github@gmail.com<mailto:vijaykumarjain.github@gmail.com>> wrote:
Just keeping it in a separate email, incase this is thrashed down.
vacuum full has a lot of problem stories, not just because the db gets locked, but also because it is mostly (mis)used when there are space issues.
ok ignore.
I think querying the disk for available space may be shell access from the client, a security issue.
Also, a 10GB table with all dead tuples is 100% bloat, and would not really need additional space for table rebuilds.
I think we can just put out some queries like bloat estimation of relations, to get an idea of wasted space and used space
and estimate based on that on how much would be taken up from the disk before being cleaned up.
ref queries: PostgresQL Automating VACUUM FULL for bloated tables - Stack Overflow<https://stackoverflow.com/questions/13931989/postgresql-automating-vacuum-full-for-bloated-tables>
--
Thanks,
Vijay
Mumbai, India
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.