Re: FW: VACUUM FULL Error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hayes, Patrick" <Patrick(dot)Hayes(at)stryker(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FW: VACUUM FULL Error
Date: 2016-12-29 15:23:18
Message-ID: 20179.1483024998@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hayes, Patrick" <Patrick(dot)Hayes(at)stryker(dot)com> writes:
> Any suggestion how to get around this issue I am having with vacuum command I’m running on 8.1 version of prostgre SQL.

You realize, I hope, that 8.1 has been out of support for more than six
years.

> The VACUUM FULL command seems to get stuck on vacuuming "pg_catalog.pg_largeobject" (last message for Verbose)

If that table is very large --- check with, eg,
select pg_size_pretty(pg_relation_size('pg_largeobject'));
then VACUUM FULL is going to take a heck of a long time, particularly
with the old implementation that was used in 8.1. But if your objective
is to return disk space to the OS, you may not have much choice; plain
VACUUM doesn't try very hard to do that.

> Error message reads as follows:
> ERROR: out of memory
> DETAIL: Failed on request of size 134217728.

I'm assuming that you are saying that VACUUM FULL fails with that, which
is not what "getting stuck" seems to mean otherwise.

If that happens to be equal to your current maintenance_work_mem setting,
you could probably dodge the problem by reducing maintenance_work_mem.
That would make it even slower :-( but at least you'd have hope of
completing eventually.

Personally I'd think very hard about going the dump-and-restore route and
updating to a somewhat modern version of Postgres while you're at it.
There are an awful lot of known bugs in 8.1, even assuming that you're
on the last minor release 8.1.23.

Updating to an OS that's still supported by its maker would be a bright
move as well.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2016-12-29 15:47:28 Re: Compiler warnings
Previous Message Dean Rasheed 2016-12-29 15:22:27 Re: Improving RLS planning