Feedback-ID: ia2694551:Fastmail
Date: Wed, 21 Aug 2024 13:21:49 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: suryasp1010@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18507: See C include file "ntstatus.h" for a description of
 the hexadecimal value.
Message-ID: <202408211721.diphtrjwwjf4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <18507-60e31665bd72615a@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/202408211721.diphtrjwwjf4%40alvherre.pgsql>
Precedence: bulk

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): Permission denied
> 2024-06-12 19:46:37.778 CST [8548] CONTEXT:  WAL redo at DFFA/F30FA990 for Heap/INSERT: off 49 flags 0x00; blkref #0: rel 1663/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