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
...@commandprompt.com 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
CONTEXT: automatic
.
Alvaro Herrera wrote:
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
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
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
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
The following bug has been logged online:
Bug reference: 5321
Logged by: Jerry Gamache
Email address: jerry.gama...@idilia.com
PostgreSQL version: 8.4.2
Operating system: Linux
Description:Parallel restore temporarily deadlocked by autovacuum
analyze
Details:
While
Here is your Sql run in a DB2 database.
connect to phoenix
Database Connection Information
Database server= DB2/LINUX 8.1.5
SQL authorization ID = GILL
Local database alias = PHOENIX
create table tab (col integer)
DB2I The SQL command completed successfully.
select 1
Just an interesting side note here, this behavior is identical to DB2. I am not
sure if that makes it correct or not, but here is an example.
[EMAIL PROTECTED] gill]$ db2 select 2 as id, max(apn3) from phoenix.client
where 2 =1
ID 2
--- --
2 -
1 record(s)
Lane
Sent: Tuesday, March 08, 2005 11:15 AM
To: Gill, Jerry T.
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #1528: Rows returned that should be excluded by
WHERE clause
Gill, Jerry T. [EMAIL PROTECTED] writes:
Just an interesting side note here, this behavior is identical to DB2. I am
I shortened the error msg to fit it into the subject box.
I just completed a fresh install (not upgrade) of MDK 9.2 onto a 1.0 GHz
Athlon with 512 MB of RAM. The PostgreSQL 7.3.4 RPMs were installed when I
did the MDK 9.2 install, which also created the postgres account.
The 'short version'
.
Ted
Postgres is not a 'database', it is the account name which owns the commands
and the directories with which and into which the database structure is
created using initdb. If you followed the short installation version you
would have done something like this:
jerry$ su
[EMAIL PROTECTED] mkdir
12 matches
Mail list logo
