BUG #16881: error log:Npgsql.PostgresException (0x80004005): XX001: 无法读取文件"base/16394/25021"的块157:只读取了8192字节的0

Started by PG Bug reporting formabout 5 years ago3 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 16881
Logged by: 宇森 孙
Email address: sun623227787@qq.com
PostgreSQL version: 9.6.0
Operating system: Windows Server 2016 64bit Datacenter
Description:

error log:
Npgsql.PostgresException (0x80004005): XX001:
无法读取文件"base/16394/25021"的块157:只读取了8192字节的0

How should I do?
It's so important for me.
Thank you!

#2Julien Rouhaud
rjuju123@gmail.com
In reply to: PG Bug reporting form (#1)
Re: BUG #16881: error log:Npgsql.PostgresException (0x80004005): XX001: 无法读取文件"base/16394/25021"的块157:只读取了8192字节的0

On Mon, Feb 22, 2021 at 4:32 PM PG Bug reporting form
<noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference: 16881
Logged by: 宇森 孙
Email address: sun623227787@qq.com
PostgreSQL version: 9.6.0
Operating system: Windows Server 2016 64bit Datacenter
Description:

error log:
Npgsql.PostgresException (0x80004005): XX001:
无法读取文件"base/16394/25021"的块157:只读取了8192字节的0

The error (which is "could not read block %u in file \"%s\": read only
%d of %d bytes") should have more details in the postgres logs,
including the reason for that error. Can you show the full error
message from the postgres logs? This could be the side effect or an
antivirus software, or some disk error or many other things.

#3Julien Rouhaud
rjuju123@gmail.com
In reply to: PG Bug reporting form (#1)
Re: BUG #16881: error log:Npgsql.PostgresException (0x80004005): XX001: 无法读取文件"base/16394/25021"的块157:只读取了8192字节的0

Hi,

Please keep the mailing list in Cc, and please don't top post.

On Wed, Feb 24, 2021 at 5:34 PM 孙宇森 <sun623227787@qq.com> wrote:

Only this error log.

Really, there wasn't any additional line with "STATEMENT:" or "HINT:" nearby?

I tried to scan the disk and found no bad path; I tried
to query for deadlock, the sentence is as follows: select * from PG_ stat_
Activity where datname ='cms'; as a result, there is no deadlock process.
"wait_event_type"and"wait_event" is null.

You likely won't see any sign of that problem in pg_stat_activity.
Can you connect to the target database (I'm assuming "cms") and run
this query:

SELECT relname FROM pg_class WHERE relfilenode = 25021;

This will give you the name of the affected relation. If that's a
table you can check doing a "SELECT * FROM the_table" to see if the
problem is still there or not. Otherwise just rebuild the index or
recreate the materialized view. Be careful, the above query will only
give you an unqualified relation name, if you have multiple schema
containing the same object names, check in the catalogs to see which
schema should be used.