Re: Urgent Help Required

I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.

backend> vacuum full debug;
WARNING: database "debug" must be vacuumed within 999999 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
ERROR: relation "debug" does not exist
backend> vacuum full;
WARNING: database "debug" must be vacuumed within 999998 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999997 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999996 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999995 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999994 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999993 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999992 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999991 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999990 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999989 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999988 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999987 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999986 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999985 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999984 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
WARNING: database "debug" must be vacuumed within 999983 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
ERROR: could not access status of transaction 449971277
DETAIL: could not open file "pg_clog/01AD": No such file or directory

Now what?

Thanks in advance.

Shailesh Singh

On 10/08/2013 03:55 AM, shailesh singh wrote:
> I had got this message while running vacuum full from backend . Now My
> database is not starting , Help pls.
>
> backend> vacuum full debug;
> WARNING: database "debug" must be vacuumed within 999999 transactions
> HINT: To avoid a database shutdown, execute a full-database VACUUM in
> "debug".
> ERROR: relation "debug" does not exist

>
> Now what?

First some information.

1) What version of Postgres are you using?

2) Does database debug in fact exist or not?
In other words does it show up with \l in psql?

Also it not necessary to use FULL with the VACUUM.

>
> Thanks in advance.
>
> Shailesh Singh

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com

Adrian Klaver-3 wrote
> On 10/08/2013 03:55 AM, shailesh singh wrote:
>> I had got this message while running vacuum full from backend . Now My
>> database is not starting , Help pls.
>>
>> backend> vacuum full debug;
>> WARNING: database "debug" must be vacuumed within 999999 transactions
>> HINT: To avoid a database shutdown, execute a full-database VACUUM in
>> "debug".
>> ERROR: relation "debug" does not exist
>
>>
>> Now what?
>
> First some information.
>
> 1) What version of Postgres are you using?
>
> 2) Does database debug in fact exist or not?
> In other words does it show up with \l in psql?
>
> Also it not necessary to use FULL with the VACUUM.
>
>>
>> Thanks in advance.
>>
>> Shailesh Singh

From the documentation:

http://www.postgresql.org/docs/9.2/interactive/sql-vacuum.html

"With no parameter, VACUUM processes every table in the current database
that the current user has permission to vacuum. With a parameter, VACUUM
processes only that table."

Since you must be connected to a database to issue VACUUM to specify which
database would be redundant. Your specification of "debug" in the above
command was not taken to be a database but rather a relation/table.

The basic steps are:

1) connect to the "debug" database.
2) issue the command "VACUUM" with no parameters

The reason for the error is that transaction id wraparound is on the verge
of occurring. After having solved the immediate problem by manually
vacuuming you should try and describe to us why it is the auto-vacuum
service has failed to vacuum the debug database in time to prevent the
warning.

The immediate solution will work on any version but the cause analysis will
require knowing the PostgreSQL versions, its configuration, and basic usage
characteristics. Regardless, though, always provide version information when
asking for help.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Urgent-Help-Required-tp5773675p5773692.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Dear all,
First of all i wish to share actual error meassge,

Below are the queries i had executed on the terminal on my server

-bash-3.2$ touch fix.sql
-bash-3.2$ echo "VACUUM FULL;" > fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold < fix.sql
WARNING: database "patnadbold" must be vacuumed within 1000000 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 1000000 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".

PostgreSQL stand-alone backend 8.1.11
backend> WARNING: database "patnadbold" must be vacuumed within 999999
transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999998 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999997 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999996 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999995 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999994 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999993 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999992 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999991 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999990 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999989 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999988 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999987 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999986 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999985 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
WARNING: database "patnadbold" must be vacuumed within 999984 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"patnadbold".
ERROR: could not access status of transaction 33011
DETAIL: could not open file "pg_clog/0000": No such file or directory
exit

After this i am able to stop /start my db server but i am not able to
connect to my databases (it tells to run vacuum full first on patnadbold
databases)

1)I am using postgres 8.4 version.
2) I had two databases on this server i) patnadbold ii) patnaonlinedb

For me patnadbold is of no use if at this moment i lost this database that
also fine to me.
I wanted to connect patnaonlinedb any how and wanted to perform backup of
this , Solution please.

On Tue, Oct 8, 2013 at 6:19 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>wrote:

> On 10/08/2013 03:55 AM, shailesh singh wrote:
>
>> I had got this message while running vacuum full from backend . Now My
>> database is not starting , Help pls.
>>
>> backend> vacuum full debug;
>> WARNING: database "debug" must be vacuumed within 999999 transactions
>> HINT: To avoid a database shutdown, execute a full-database VACUUM in
>> "debug".
>> ERROR: relation "debug" does not exist
>>
>
>
>> Now what?
>>
>
> First some information.
>
> 1) What version of Postgres are you using?
>
> 2) Does database debug in fact exist or not?
> In other words does it show up with \l in psql?
>
> Also it not necessary to use FULL with the VACUUM.
>
>
>
>> Thanks in advance.
>>
>> Shailesh Singh
>>
>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)gmail(dot)com
>

--
With Regards,
शैलेश सिंह |Shailesh Singh
+९१-९६५०३१७५१७ | +91-9650317517

On Tue, Oct 8, 2013 at 8:03 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:

> HINT: To avoid a database shutdown, execute a full-database VACUUM in
> "patnadbold".
> ERROR: could not access status of transaction 33011
> DETAIL: could not open file "pg_clog/0000": No such file or directory
> exit
>
>
> After this i am able to stop /start my db server but i am not able to
> connect to my databases (it tells to run vacuum full first on patnadbold
> databases)
>

The message does *not* say to run "VACUUM FULL", it says to run a
"full-database VACUUM". Different things.
Connect to "patnadbold" and issue "VACUUM;" (without double-quotes) as the
others have suggested.

On 10/08/2013 08:03 AM, shailesh singh wrote:
> Dear all,
> First of all i wish to share actual error meassge,
>
> Below are the queries i had executed on the terminal on my server
>
>
> -bash-3.2$ touch fix.sql
> -bash-3.2$ echo "VACUUM FULL;" > fix.sql
> -bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold < fix.sql
> WARNING: database "patnadbold" must be vacuumed within 1000000 transactions
> HINT: To avoid a database shutdown, execute a full-database VACUUM in
> "patnadbold".
> WARNING: database "patnadbold" must be vacuumed within 1000000 transactions
> HINT: To avoid a database shutdown, execute a full-database VACUUM in
> "patnadbold".
>
> PostgreSQL stand-alone backend 8.1.11

>
> After this i am able to stop /start my db server but i am not able to
> connect to my databases (it tells to run vacuum full first on patnadbold
> databases)
>
>
> 1)I am using postgres 8.4 version.

This seems to be at odds with "PostgreSQL stand-alone backend 8.1.11".
Are you sure you are working on the correct database cluster?

> 2) I had two databases on this server i) patnadbold ii) patnaonlinedb
>
> For me patnadbold is of no use if at this moment i lost this database
> that also fine to me.
> I wanted to connect patnaonlinedb any how and wanted to perform backup
> of this , Solution please.
>

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com

On Tue, Oct 08, 2013 at 08:06:50AM -0700, bricklen wrote:
> On Tue, Oct 8, 2013 at 8:03 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>
> > HINT: To avoid a database shutdown, execute a full-database VACUUM in
> > "patnadbold".
> > ERROR: could not access status of transaction 33011
> > DETAIL: could not open file "pg_clog/0000": No such file or directory
> > exit
> >
> >
> > After this i am able to stop /start my db server but i am not able to
> > connect to my databases (it tells to run vacuum full first on patnadbold
> > databases)
> >
>
> The message does *not* say to run "VACUUM FULL", it says to run a
> "full-database VACUUM". Different things.
> Connect to "patnadbold" and issue "VACUUM;" (without double-quotes) as the
> others have suggested.

In case it isn't clear to the original poster, VACUUM FULL will take a
lot longer than a simple VACUUM and probably not really help much.

Just plain VACUUM.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer

On Tue, Oct 8, 2013 at 8:13 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:

>
> On Tue, Oct 8, 2013 at 8:36 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>
>>
>> On Tue, Oct 8, 2013 at 8:03 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>>
>>> HINT: To avoid a database shutdown, execute a full-database VACUUM in
>>> "patnadbold".
>>> ERROR: could not access status of transaction 33011
>>> DETAIL: could not open file "pg_clog/0000": No such file or directory
>>> exit
>>>
>>>
>>> After this i am able to stop /start my db server but i am not able to
>>> connect to my databases (it tells to run vacuum full first on patnadbold
>>> databases)
>>>
>>
>> The message does *not* say to run "VACUUM FULL", it says to run a
>> "full-database VACUUM". Different things.
>> Connect to "patnadbold" and issue "VACUUM;" (without double-quotes) as
>> the others have suggested.
>>
>
> When i am trying to connect "patnadbold" , it is giving error for "execute
> a full-database VACUUM in "patnadbold" " .
> is there any way to connect this database using backend process . pl let
> me know the command sequnce i need to run.
> Thanks.
>

Please keep replies CC'd to the pgsql-general list, and follow the format
of the other messages, which is to bottom-post.

You need to show (again?) exactly what you are executing. Are you
connecting via psql or using another command? Are you connecting directly
to that "patnadbold" database? If you are able to connect to it, are you
able to issue just "VACUUM;" ?

yes i am executing psql to connect to this database.

su - postgres
psql patnadbold

On Tue, Oct 8, 2013 at 8:48 PM, bricklen <bricklen(at)gmail(dot)com> wrote:

>
>
>
> On Tue, Oct 8, 2013 at 8:13 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>
>>
>> On Tue, Oct 8, 2013 at 8:36 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>>
>>>
>>> On Tue, Oct 8, 2013 at 8:03 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>>>
>>>> HINT: To avoid a database shutdown, execute a full-database VACUUM in
>>>> "patnadbold".
>>>> ERROR: could not access status of transaction 33011
>>>> DETAIL: could not open file "pg_clog/0000": No such file or directory
>>>> exit
>>>>
>>>>
>>>> After this i am able to stop /start my db server but i am not able to
>>>> connect to my databases (it tells to run vacuum full first on patnadbold
>>>> databases)
>>>>
>>>
>>> The message does *not* say to run "VACUUM FULL", it says to run a
>>> "full-database VACUUM". Different things.
>>> Connect to "patnadbold" and issue "VACUUM;" (without double-quotes) as
>>> the others have suggested.
>>>
>>
>> When i am trying to connect "patnadbold" , it is giving error for
>> "execute a full-database VACUUM in "patnadbold" " .
>> is there any way to connect this database using backend process . pl let
>> me know the command sequnce i need to run.
>> Thanks.
>>
>
> Please keep replies CC'd to the pgsql-general list, and follow the format
> of the other messages, which is to bottom-post.
>
> You need to show (again?) exactly what you are executing. Are you
> connecting via psql or using another command? Are you connecting directly
> to that "patnadbold" database? If you are able to connect to it, are you
> able to issue just "VACUUM;" ?
>
>
>
>
>

--
With Regards,
शैलेश सिंह |Shailesh Singh
+९१-९६५०३१७५१७ | +91-9650317517

On Tue, Oct 8, 2013 at 8:25 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:

> yes i am executing psql to connect to this database.
>
> su - postgres
> psql patnadbold
>

..and then what? Does it immediately throw an error stating that you must
issue a VACUUM?

First, while vacuum is usually preferred to vacuum full, in this case, I
usually find that vacuum full clears up enough cruft to be worth it (not
always, but especially if you are also having performance issues).

Secondly I would recommend using the vacuumdb command from the shell
instead of psql because it has some features that will help avoid some
issues.

Try:

vacuumdb -a

Or if you want to force reclaim space (if you are suffering from db bloat
relating to not vacuuming:

vacuumdb -f -a

You may need to run this as the postgres user. It accepts the same
parameters for authentication that psql does.

Best Wishes,
Chris Travers

On Tue, Oct 8, 2013 at 8:25 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:

> yes i am executing psql to connect to this database.
>
> su - postgres
> psql patnadbold
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 8, 2013 at 8:48 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>
>>
>>
>>
>> On Tue, Oct 8, 2013 at 8:13 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>>
>>>
>>> On Tue, Oct 8, 2013 at 8:36 PM, bricklen <bricklen(at)gmail(dot)com> wrote:
>>>
>>>>
>>>> On Tue, Oct 8, 2013 at 8:03 AM, shailesh singh <shaileshjuly(at)gmail(dot)com>wrote:
>>>>
>>>>> HINT: To avoid a database shutdown, execute a full-database VACUUM in
>>>>> "patnadbold".
>>>>> ERROR: could not access status of transaction 33011
>>>>> DETAIL: could not open file "pg_clog/0000": No such file or directory
>>>>> exit
>>>>>
>>>>>
>>>>> After this i am able to stop /start my db server but i am not able to
>>>>> connect to my databases (it tells to run vacuum full first on patnadbold
>>>>> databases)
>>>>>
>>>>
>>>> The message does *not* say to run "VACUUM FULL", it says to run a
>>>> "full-database VACUUM". Different things.
>>>> Connect to "patnadbold" and issue "VACUUM;" (without double-quotes) as
>>>> the others have suggested.
>>>>
>>>
>>> When i am trying to connect "patnadbold" , it is giving error for
>>> "execute a full-database VACUUM in "patnadbold" " .
>>> is there any way to connect this database using backend process . pl let
>>> me know the command sequnce i need to run.
>>> Thanks.
>>>
>>
>> Please keep replies CC'd to the pgsql-general list, and follow the format
>> of the other messages, which is to bottom-post.
>>
>> You need to show (again?) exactly what you are executing. Are you
>> connecting via psql or using another command? Are you connecting directly
>> to that "patnadbold" database? If you are able to connect to it, are you
>> able to issue just "VACUUM;" ?
>>
>>
>>
>>
>>
>
>
> --
> With Regards,
> शैलेश सिंह |Shailesh Singh
> +९१-९६५०३१७५१७ | +91-9650317517
>
>
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml

> postgres -D /var/lib/pgsql/data patnadbold < fix.sql

What the heck is the point of feeding "VACUUM FULL;" into the standard input
of the postgres command? "postgres" simply starts the server, it does not
execute arbitrary SQL. Once the database is started you want to use "psql"
- either interactively or in a similar manner to the above - to connect to
the <patnadbold> database and run "VACUUM".

Note that: "su postgres" -> "psql" will likely connect you to the
"postgres" database as that is the normal default. You will need to tell
psql which database to connect to.

> PostgreSQL stand-alone backend 8.1.11

8.1 is unsupported at this point; plus you say 8.4 below which this
contradicts. Your configuration is very unclear.

> ERROR: could not access status of transaction 33011
> DETAIL: could not open file "pg_clog/0000": No such file or directory
> exit

This is bothersome as well...

> After this i am able to stop /start my db server but i am not able to
> connect to my databases (it tells to run vacuum full first on patnadbold
> databases)
>
>
> 1)I am using postgres 8.4 version.
> 2) I had two databases on this server i) patnadbold ii) patnaonlinedb
>
> For me patnadbold is of no use if at this moment i lost this database that
> also fine to me.
> I wanted to connect patnaonlinedb any how and wanted to perform backup of
> this , Solution please.

The only thing not mentioned is starting postgres is single-user mode; this
may be necessary though I am not sure and others can be of more help.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Urgent-Help-Required-tp5773675p5773716.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

*Don't* VACUUM FULL. Just VACUUM. It's not the same thing.

...Robert

On 10/08/2013 09:03 AM, David Johnston wrote:
>
>> postgres -D /var/lib/pgsql/data patnadbold < fix.sql
>
> What the heck is the point of feeding "VACUUM FULL;" into the standard input
> of the postgres command? "postgres" simply starts the server, it does not
> execute arbitrary SQL. Once the database is started you want to use "psql"
> - either interactively or in a similar manner to the above - to connect to
> the <patnadbold> database and run "VACUUM".

I was under that impression also. So I went back in the archives, and in
8.1 this was possible.

http://www.postgresql.org/docs/8.1/interactive/app-postgres.html

>
>
>> PostgreSQL stand-alone backend 8.1.11
>
> 8.1 is unsupported at this point; plus you say 8.4 below which this
> contradicts. Your configuration is very unclear.

This part is still unclear to me. I would like some more information on
where the 8.4 cluster comes into play, if at all. My hunch is the OP is
working with two different Postgres instances un-intently .

> David J.

--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com

On 10/8/13 5:55 AM, shailesh singh wrote:
> HINT: To avoid a database shutdown, execute a full-database VACUUM in "debug".
> ERROR: could not access status of transaction 449971277
> DETAIL: could not open file "pg_clog/01AD": No such file or directory

Unless I'm mistaken, that missing CLOG file is a bad sign...?
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

On 10/8/2013 8:35 AM, Chris Travers wrote:
> First, while vacuum is usually preferred to vacuum full, in this case,
> I usually find that vacuum full clears up enough cruft to be worth it
> (not always, but especially if you are also having performance issues).

IIRC, vacuum full was pretty broken in 8.1, which the output the
original postered showed indicated they were running.

--
john r pierce 37N 122W
somewhere on the middle of the left coast

On Wed, Oct 9, 2013 at 7:04 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:

> On 10/8/2013 8:35 AM, Chris Travers wrote:
>
>> First, while vacuum is usually preferred to vacuum full, in this case, I
>> usually find that vacuum full clears up enough cruft to be worth it (not
>> always, but especially if you are also having performance issues).
>>
>
>
> IIRC, vacuum full was pretty broken in 8.1, which the output the original
> postered showed indicated they were running.

I certainly wouldn't recommend it for routine maintenance. The problem I
have run into is that sometimes folks don't vacuum db's and you find this
out after 7 years of write-heavy workloads..... In this case, there aren't
a lot of great options. In 8.1 a normal vacuum will usually lead to tons
of bloat in this case because the FSM isn't big enough to accommodate all
the free space which is a problem. So at that point, vacuum without the
full option is pretty broken in 8.1 :-P I often find in those cases it is
a choice between vacuum full and dumpall/initdb/reload/analyze..... It is
better now that there is no maximum size for the free space map though.

Best Wishes,
Chris travers

>
>
> --
> john r pierce 37N 122W
> somewhere on the middle of the left coast
>
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>

--
Best Wishes,
Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml

Chris Travers <chris(dot)travers(at)gmail(dot)com> wrote:
> John R Pierce <pierce(at)hogranch(dot)com> wrote:

> I often find in those cases it is a choice between vacuum full
> and dumpall/initdb/reload/analyze.....

Way back in the 8.1 days I often found CLUSTER to be my best option
-- as long as I had room enough for a second copy (without the
bloat) while it was running.  If I didn't have that much room the
dump/initdb/restore option was almost always faster than VACUUM
FULL.  Personally, I would follow the restore with VACUUM FREEZE
ANALYZE rather than just ANALYZE, so that the entire database
didn't come due for wraparond prevention vacuums at an inopportune
time.

The main thing here seem to be to upgrade to a supported version
(preferably 9.2 or 9.3).

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company