Re: BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value.
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value. |
Дата | |
Msg-id | 202408211721.diphtrjwwjf4@alvherre.pgsql обсуждение исходный текст |
Ответ на | BUG #18507: See C include file "ntstatus.h" for a description of the hexadecimal value. (PG Bug reporting form <noreply@postgresql.org>) |
Список | 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 по дате отправления: