Re: vacuumlo

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Ian Dauncey <Ian(dot)Dauncey(at)bankzero(dot)co(dot)za>, "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: vacuumlo
Date: 2021-08-30 17:15:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-admin pgsql-general

On Mon, 2021-08-30 at 15:08 +0000, Ian Dauncey wrote: 
> I did run the vacuumlo  against the pg_largeobject table without any issues but afterwards
> I ran a vacuum full against this table which caused lots of issues.
> Because the vacuum full takes an exclusive lock (which was my first mistake as I
> did not stop the applications accessing the database) on the table I had all the
> applications hanging.


> The next issue was it started writing out WAL logs and in the end the file system
> which housed the Wal logs filled up causing the vacuum to fail.
> Now the issue I have here is that the vacuum full created a temporary table , and when
> it crashed this temporary table did not get deleted. I did rerun the vacuum full against
> the pg_largeobject table (and yes, I did stop all the applications first).
> It did complete successfully but it did not drop the previous temporary table.
> This table is taking close to 100 Gig of disk space.

VACUUM (FULL) will write a compact copy of the table, then delete the old one,
so it temporarily needs more space. It may be a good idea to put "pg_wal" into
a different file system, so that WAL space cannot run out even if the data files
fill the file system. Then PostgreSQL won't crash, and the files will be removed.
> If I backup and restore the database onto a different server this temporary table does not get restored.
> My question here is.
>    1. How do I get rid of this temporary table without a backup and restore as this is our Prod system?

You cannot :^(
If you know PostgreSQL well, and you know what you are doing, you might be able
to identify those files and manually delete them. But that's definitely not
something for the casual user: delete the wrong file, and you have to restore
the backup.

>    2. Is there a way of finding out the name of this temp table and matching it up to files on disk?

No, unfortunately not.
You'd have to identify the files that do *not* belong to any table, and that
is tricky.

Laurenz Albe
Cybertec |

In response to


Browse pgsql-admin by date

  From Date Subject
Next Message Mladen Gogala 2021-08-30 17:38:14 Re: vacuumlo
Previous Message Tom Lane 2021-08-30 16:53:25 Re: FW: vacuumlo

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2021-08-30 17:33:42 Re: Can we get rid of repeated queries from pg_dump?
Previous Message Tom Lane 2021-08-30 16:53:25 Re: FW: vacuumlo