After I restart postgresql, I execute vacuum several times in sql until it succeeds. Then, everything else works OK again.
After I clear the problem,
select count(*) from archive
takes a second but, before the problem is cleared, it takes about 30 seconds and then gives the canceled by user response.
The vacuum was run using the vacuumdb command rather than from psql. It was in a cron script running under user postgres. There was a .pgpass file. The command was
/usr/bin/vacuumdb --all --full --analyze
This is postgresql on Red Hat Enterprise Linux 3 (ES) from RPMs postgresql-7.4.3-2PGDG, etc.
My postgresql.conf file had a 10 second timeout and the large database
required more than 10 seconds for the vacuum. It seems that this left
postmaster and/or the particular database in a state where any SQL
against that database gave the same error response about being canceled
by the user.
Hmm, I couldn't duplicate this. I thought maybe the vacuum wasn't
releasing some lock after it failed, but there's no sign of such a
problem.
Are you sure it isn't just that all your queries were running into the
timeout?
regards, tom lane
.
