0

We have PostgreSQL 14 on Windows Server 2019 where autovacuum processes crash the database server. This is affecting our production environment with 80+ daily users, and I need urgent assistance.

Environment:

  • PostgreSQL 14.17, compiled by Visual C++ build 1942, 64-bit
  • Windows Server 2019 Standard
  • Intel Xeon Processor Ice Lake / Memory 160GB
  • Configuration: autovacuum = on, wal_level = hot_standby
  • PostgreSQL service running as superuser
  • No antivirus software interfering

Problem Description:

Autovacuum is enabled server-wide for the entire PostgreSQL instance, but crashes occur specifically when processing tables within a particular database (identified by OID).

The server experiences permission denied errors on various blocks, the database service crashes with exception 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN), then the server restarts.

This occurs randomly across different system catalog tables and user tables within this specific database.

Reproducible Conditions:

  • autovacuum = on → Crashes occur
  • autovacuum = off → No crashes
  • Tested with wal_level = minimal (disabled replication) → Still crashes
  • Restored database to different disk location → Same issue persists

Error Pattern Examples:

original log:

2025-10-23 16:18:37.963 KST [13660] [] []손상: "pg_tblspc/16396/PG_14_202107181/564019643/590692149.2" 파일을 315808 블럭으로 정리할 수 없음: Permission denied 
2025-10-23 16:18:37.963 KST [13660] [] []내용: "pg_catalog.pg_attribute" 릴레이션을 315808 블럭으로 줄이는 중 2025-10-23 16:18:38.257 KST [7444] [] []로그: 서버 프��세스 (PID 13660) 프로세스가 0xC0000409 예외로 인해 종료됨 
2025-10-23 16:18:38.257 KST [7444] [] []상세정보: Failed process was running: autovacuum: VACUUM ANALYZE pg_catalog.pg_attribute 
2025-10-23 16:18:38.257 KST [7444] [] []힌트: 16진수 값에 대한 설명은 C 포함 파일 "ntstatus.h"를 참조하십시오. 
2025-10-23 16:18:38.257 KST [7444] [] []로그: 다른 활성화 되어있는 서버 프로세스를 마치고 있는 중입니다
2025-10-24 16:20:53.335 KST [12604] [] []손상: "pg_tblspc/16396/PG_14_202107181/564019643/590691805" 파일을 13 블럭으로 정리할 수 없음: Permission denied 
2025-10-24 16:20:53.335 KST [12604] [] []내용: "pg_catalog.pg_sequence" 릴레이션을 13 블럭으로 줄이는 중 
2025-10-24 16:20:53.462 KST [7444] [] []로그: 서버 프로세스 (PID 12604) 프로세스가 0xC0000409 예외로 인해 종료됨 
2025-10-24 16:20:53.462 KST [7444] [] []상세정보: Failed process was running: autovacuum: VACUUM ANALYZE pg_catalog.pg_sequence 
2025-10-24 16:20:53.462 KST [7444] [] []힌트: 16진수 값에 대한 설명은 C 포함 파일 "ntstatus.h"를 참조하십시오. 
2025-10-24 16:20:53.462 KST [7444] [] []로그: 다른 활성화 되어있는 서버 프로세스를 마치고 있는 중입니다

translate log in English

2025-10-23 16:18:37.963 KST [13660] ERROR: could not truncate file "pg_tblspc/16396/PG_14_202107181/564019643/590692149.2" to 315808 blocks: Permission denied 
2025-10-23 16:18:37.963 KST [13660] CONTEXT: truncating relation "pg_catalog.pg_attribute" to 315808 blocks 
2025-10-23 16:18:38.257 KST [7444] LOG: server process (PID 13660) was terminated by exception 0xC0000409 
2025-10-23 16:18:38.257 KST [7444] DETAIL: Failed process was running: autovacuum: VACUUM ANALYZE pg_catalog.pg_attribute
2025-10-24 15:42:49.925 KST [9980] ERROR: could not truncate file "pg_tblspc/16396/PG_14_202107181/564019643/590692721" to 43 blocks: Permission denied 
2025-10-24 15:42:49.925 KST [9980] CONTEXT: truncating relation "hdmap.hdtn_lock" to 43 blocks 
2025-10-24 15:42:50.728 KST [7444] LOG: server process (PID 9980) was terminated by exception 0xC0000409

Key Observations:

  • Affects both system catalogs (pg_catalog.pg_attribute, pg_catalog.pg_sequence) and user tables
  • Following permission denied errors, the PostgreSQL service initiates a restart process, causing all active connections and transactions to be terminated
  • 0xC0000409 exception (STATUS_STACK_BUFFER_OVERRUN) consistently follows permission errors
  • Database serves ~80 concurrent users with significant daily transaction volume
  • Issue persists even after full backup/restore to different storage location Hardware specs should be more than adequate (Intel Xeon Ice Lake, 160GB RAM)

Troubleshooting Attempted:

  • Verified PostgreSQL service permissions (running as superuser)
  • Disabled replication (wal_level = minimal)
  • Moved database to different disk location
  • Confirmed no antivirus interference
  • Issue only occurs with this specific database Running PostgreSQL 14.17 version

Questions:

  1. Root Cause: What could cause systematic permission denied errors during autovacuum truncation operations on Windows despite adequate hardware resources?

  2. Similar Cases: Has anyone encountered this specific pattern of autovacuum crashes with 0xC0000409 exceptions?

  3. Immediate Solution: How can I resolve this issue to safely re-enable autovacuum?

  4. Alternative Approaches: If this cannot be resolved, what are recommended alternatives for maintaining this high-transaction database?

This is critically impacting our production environment. Any insights, workarounds, or diagnostic suggestions would be greatly appreciated.

Improve this question
15
  • Was the backup/restore done via pg_dump or by copying the database files themselves? Commented Oct 30 at 5:44
  • @SimonRichter I copied and pasted the database using the DBeaver program, then deleted the existing database and renamed the copied one to the original name. Commented Oct 30 at 6:22
  • Not sure how that program works -- if it just moved the files around, it may still be a permission problem on the files (superuser doesn't automatically override permissions, but is allowed to change them -- shell commands do that, postgres doesn't). Commented Oct 30 at 7:24
  • What is a bit suspicious is that a VACUUM in a freshly restored backup even does anything. Commented Oct 30 at 7:46
  • Also, postgres will typically not run as superuser, but it will switch to the postgres user, because there is no need for privileges. Commented Oct 30 at 7:46

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.