Re: BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value. - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value.
Date
Msg-id 202408211721.diphtrjwwjf4@alvherre.pgsql
Whole thread Raw
In response to BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value.  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
Hi, sorry for replying to such an old thread, but I see there are no
other replies.

On 2024-Jun-13, PG Bug reporting form wrote:

> 2024-06-12 19:31:55.194 CST [16044] PANIC:  could not fsync file "base/16510/692021.1": Permission denied
> [...]
> 2024-06-12 19:32:12.312 CST [21708] LOG:  terminating any other active server processes

According to these lines, it took 17 seconds since raising the PANIC
until postmaster managed to process the signal and started to take
processes down.  This isn't the highest I've seen, but it's high enough
to be concerning.  You're likely overloading the machine.  This isn't
the actual cause of the problem you're reporting, but it seems a rather
bad idea and will give you a bad experience.  You should have a
connection pooler and limit the number of maximum connections you allow
in the database directly.  Also, consider giving it more CPU power, more
storage bandwidth, maybe more memory (though extra RAM by itself is
unlikely to achieve much in this case).

> 2024-06-12 19:46:37.778 CST [8548] FATAL:  could not open file "base/20846/24818.12" (target block 1572864):
Permissiondenied
 
> 2024-06-12 19:46:37.778 CST [8548] CONTEXT:  WAL redo at DFFA/F30FA990 for Heap/INSERT: off 49 flags 0x00; blkref #0:
rel1663/20846/24818, blk 7975034 FPW
 

So do you have an antivirus?  Maybe you can configure it to skip the
Postgres data files.  Otherwise this kind of problem is going to bite
you hard.

> Later when we startup the database manually it started very slow. frequent
> connectivity issues are there now.

Probably it had way too much recovery to perform, which suggests your
checkpoint settings need tightening so that they occur more frequently.
Again, this could be caused by overload.

> 
> 2024-06-13 10:36:13.261 CST [6608] LOG:  starting PostgreSQL 14.1, compiled
> by Visual C++ build 1914, 64-bit

14.1 is about 3 years out of date.  There are bugs, and you're not going
to like them.  Perhaps bugs about inability to open files that the
antivirus is scanning (I didn't actually check the git log, but we do
have fixes about that).  You need to upgrade to 14.13 with haste.

Regards

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"I'm impressed how quickly you are fixing this obscure issue. I came from 
MS SQL and it would be hard for me to put into words how much of a better job
you all are doing on [PostgreSQL]."
 Steve Midgley, http://archives.postgresql.org/pgsql-sql/2008-08/msg00000.php



pgsql-bugs by date:

Previous
From: Marcin Barczyński
Date:
Subject: Re: REINDEX INDEX pg_catalog.pg_default_acl_role_nsp_obj_index stuck waiting for transaction from the future in PG 13.16
Next
From: Weslley Braga
Date:
Subject: Postgres v16.4 crashes on segfault when memory >= 16gb