From: | "Paul B(dot) Anderson" <paul(at)pnlassociates(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Large transaction problem |
Date: | 2004-11-11 22:14:50 |
Message-ID: | 4193E45A.7050000@pnlassociates.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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:
>"Paul B. Anderson" <paul(at)pnlassociates(dot)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
>
>.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-11-11 22:48:52 | Re: Large transaction problem |
Previous Message | Tom Lane | 2004-11-11 21:07:35 | Re: Large transaction problem |