Critical autovacuum permission denied errors causing server crashes on Windows - Need urgent assistance

Dear PostgreSQL Community,

I'm experiencing a critical issue with PostgreSQL 14 on Windows Server 2019 where autovacuum processes consistently crash the entire 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 and subsequently crashes with complete server restart. 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-23 16:18:40.276 KST [12704] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.277 KST [12796] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.549 KST [13344] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.549 KST [12856] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.587 KST [13464] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.626 KST [11504] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.630 KST [14908] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.631 KST [12368] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.644 KST [14064] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.646 KST [12724] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-23 16:18:40.713 KST [14628] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
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] [] []로그:  다른 활성화 되어있는 서버 프로세스를 마치고 있는 중입니다
2025-10-24 16:20:54.802 KST [10684] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-24 16:20:54.806 KST [11576] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-24 16:20:54.807 KST [14604] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
2025-10-24 16:20:54.810 KST [9528] [hdmap_main_op_sdplus] [[알수없음]]치명적오류:  데이터베이스 시스템이 자동 복구 작업 중입니다.
translate 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:

1. Affects both system catalogs (pg_catalog.pg_attribute, pg_catalog.pg_sequence) and user tables
2. Always fails during relation truncation operations
3. 0xC0000409 exception (STATUS_STACK_BUFFER_OVERRUN) consistently follows permission errors
4. Database serves ~80 concurrent users with significant daily transaction volume
5. Issue persists even after full backup/restore to different storage location
6. 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 latest 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.

Thank you in advance for your assistance.

Best regards