Re: Large transaction problem
| От | Paul B. Anderson |
|---|---|
| Тема | Re: Large transaction problem |
| Дата | |
| Msg-id | 4193E45A.7050000@pnlassociates.com обсуждение исходный текст |
| Ответ на | Re: Large transaction problem (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Large transaction problem
Re: Large transaction problem |
| Список | pgsql-admin |
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.
Thanks.
Paul
Tom Lane wrote:
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.
Thanks.
Paul
Tom Lane wrote:
"Paul B. Anderson" <paul@pnlassociates.com> writes: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 .
В списке pgsql-admin по дате отправления: