Re: could not read, could not write, could not fsync, Windows 2000, PostgreSQL 8.0.1 - Mailing list pgsql-hackers

From Qingqing Zhou
Subject Re: could not read, could not write, could not fsync, Windows 2000, PostgreSQL 8.0.1
Date
Msg-id d0oarp$ruk$1@news.hub.org
Whole thread Raw
List pgsql-hackers
I encounter the similar problem in "make check" (win2k-mingw, 8.0.1). The
regression test could randomly fail due to "could not write block (Invalid
argument)" problem or could not "remove file" problem.

Regards,
Qingqing

p.s. I believe this could be a potential serious problem, so I forward it to
pgsql.hackers.
---

""Jean-Pierre Pelletier"" <pelletier_32@sympatico.ca>
We are running PostgreSQL 8.0.1 since last week and have these
messages in our PostgreSQL log file:

2005-02-10 10:27:19 FATAL:  could not read block 38 of relation
1663/17269/16676: Invalid argument
2005-02-10 10:27:19 FATAL:  could not read block 46 of relation
1663/17269/16676: Invalid argument
2005-02-10 10:27:19 FATAL:  could not read block 50 of relation
1663/17269/16676: Invalid argument

16676 is table "pgdepend"

2005-02-14 12:19:46 FATAL:  could not read block 7 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 20 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 22 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 14 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 18 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 24 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 8 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 19 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 11 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 21 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 25 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 23 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 13 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 9 of relation
1663/17269/1247: Invalid argument
2005-02-14 12:19:46 FATAL:  could not read block 12 of relation
1663/17269/1247: Invalid argument

1247 is table "pgtype"

2005-02-16 10:48:26 ERROR:  could not write block 61 of relation
1663/17269/16676: Invalid argument
2005-02-16 10:48:26 CONTEXT:  writing block 61 of relation 1663/17269/16676

16676 is table "pgdepend"

2005-02-16 12:47:03 ERROR:  could not write block 3 of relation
1663/17269/1614690: Invalid argument
2005-02-16 12:47:03 CONTEXT:  writing block 3 of relation 1663/17269/1614690

We couldn't find what 1614690 is?

2005-02-18 05:32:06 LOG:  could not fsync segment 0 of relation
1663/17269/1677179: Permission denied
2005-02-18 05:32:06 ERROR:  storage sync failed on magnetic disk: Permission
denied

...
2005-02-18 07:58:28 ERROR:  storage sync failed on magnetic disk: Permission
denied
2005-02-18 07:58:29 LOG:  could not fsync segment 0 of relation
1663/17269/1677179: Permission denied

These two messages are repeated every seconds for almost 2.5 hours
Again, we couldn't find what 1677179 is?

We are on Windows 2000 Server, Service Pack 4 and
were successfully running PostgreSQL 7.4.1 before that.

We have done a vacuum, analyze and reindex on pgdepend and pgtype and
restarted PostgreSQL
a few times, we had no problems doing that but the error messages are still
there.

Is this normal and if not, how do we fix that?

Thanks
Jean-Pierre Pelletier

p.s.: We also have messages "FATAL:  could not read from statistics
collector pipe" approx. twice an hour.





pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: pgpool question
Next
From: Tom Lane
Date:
Subject: We are not following the spec for HAVING without GROUP BY