Alvaro Herrera wrote:
Jerry Gamache wrote:
Yes, I have PID in the logs now. Problem was observed around 13h30,
and there was no log output between 13h18 and 13h30.
There are messages for table_b (pid 18350) and table_c (pid 18406),
but none for table_a.
Eh, but according to the pg_lock
Yes, I have PID in the logs now. Problem was observed around 13h30, and
there was no log output between 13h18 and 13h30.
There are messages for table_b (pid 18350) and table_c (pid 18406), but
none for table_a.
Alvaro Herrera wrote:
The logs show that the autovacuum of table_b was canceled 20
Here is the pg_locks output.
Alvaro Herrera wrote:
Jerry Gamache wrote:
I was not able to repro with default parameters, or at 15s naptime,
and at 1s naptime I got only 1deadlock in 3 tests.
This time the deadlock was with table_a, table_b and table_c
(table_x and table_y were not involved)
I was not able to repro with default parameters, or at 15s naptime, and
at 1s naptime I got only 1deadlock in 3 tests.
This time the deadlock was with table_a, table_b and table_c (table_x
and table_y were not involved).
18395 | database1 | autovacuum: ANALYZE public.table_a
18406 | datab
I was also surprised that table_y seemed to be involved. This is not a
typo. Might be caused by a FK constraint between table_y and table_x.
From the logs, the autovacuum on table_x was canceled before the one on
table_y, but the restore only resumed after the autovacuum on table_y
was canceled
All autovacuum and deadlock_timeout settings are at their default values
(lines are commented out in postgresql.conf).
Alvaro Herrera wrote:
Jerry Gamache wrote:
The restore resumed while I was writing this report, and I saw these new
entries in the logs:
ERROR: canceling autovacuum task
The following bug has been logged online:
Bug reference: 5322
Logged by: Eric Pailleau
Email address: e...@numlog.fr
PostgreSQL version: 8.2.3
Operating system: linux debian
Description:Time to perform vacuums
Details:
Hello,
I really don't know if it can be a bug o
Jerry Gamache wrote:
> Yes, I have PID in the logs now. Problem was observed around 13h30,
> and there was no log output between 13h18 and 13h30.
> There are messages for table_b (pid 18350) and table_c (pid 18406),
> but none for table_a.
Eh, but according to the pg_locks snap you posted, the PID
Jerry Gamache wrote:
> Here is the pg_locks output.
>
> Alvaro Herrera wrote:
> >Jerry Gamache wrote:
> >>The logs show that the autovacuum of table_b was canceled 20 minutes
> >>ago, but the thread is still alive and blocked.
Well, it's clearly locked on table_b, and that autovac is still runni
Jerry Gamache wrote:
> I was not able to repro with default parameters, or at 15s naptime,
> and at 1s naptime I got only 1deadlock in 3 tests.
>
> This time the deadlock was with table_a, table_b and table_c
> (table_x and table_y were not involved).
>
> 18395 | database1 | autovacuum: ANALYZE
Wolfgang Fahnenschreiber wrote:
> I installed on my Laptop the programm "weather professional 1.83".
>
> The program crashed today and so I installed it new. When I tried to restore
> the data base, it failed an I received the following message:
>
> pg_restore: [archiver (db)] error returned by
Jerry Gamache wrote:
> I was also surprised that table_y seemed to be involved. This is not
> a typo. Might be caused by a FK constraint between table_y and
> table_x. From the logs, the autovacuum on table_x was canceled
> before the one on table_y, but the restore only resumed after the
> autovac
Good afternoon,
I installed on my Laptop the programm "weather professional 1.83".
The program crashed today and so I installed it new. When I tried to restore
the data base, it failed an I received the following message:
pg_restore: [archiver (db)] error returned by PQputCopyData:
Alvaro Herrera writes:
> Jerry Gamache wrote:
>> The restore resumed while I was writing this report, and I saw these new
>> entries in the logs:
>>
>> ERROR: canceling autovacuum task
>> CONTEXT: automatic analyze of table "database1.public.table_y"
>> ERROR: canceling autovacuum task
>> CONT
Jerry Gamache wrote:
> The restore resumed while I was writing this report, and I saw these new
> entries in the logs:
>
> ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table "database1.public.table_y"
> ERROR: canceling autovacuum task
> CONTEXT: automatic analyze of table
Somebody will fix this bug or not?
On Thu, Feb 4, 2010 at 7:13 PM, Oleg wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5314
> Logged by: Oleg
> Email address: sero...@gmail.com
> PostgreSQL version: 8.3/8.4
> Operating system: any
> Description:
16 matches
Mail list logo
