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' for
g this doesn't create problems
> later.
>
> 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 ve
jerry wrote:
> 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 p
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
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
:
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 analyz
nd blocked.
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 on
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 to the
ould have thought
it would have everything necessary to restore the database without
a problem. I also would have expected that the INSERT INTO
statements in the testdump.sql would have appropriately updated
the primary key.
Is there something missing from the original database that got
dumped, or so
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
ECTED] Behalf Of Tom 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 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 fro
14 matches
Mail list logo
