Hello PostgreSQL Community, We ship an application that bundles PostgreSQL on Windows machines using a GUI installer. We recently noticed a critical difference in how PostgreSQL behaves depending on what is selected in the "Locale" dropdown during installation, and we need the community's guidance on the recommended approach.
Our Observation: Case A (Leaving it as Default): If we leave the installer's Locale setting as [Default Locale] on an Indian Windows machine, the resulting database shows datctype as English_India.1252 and datcollversion is completely empty (NULL). Case B (Manually typing en-IN): If we explicitly select or type en-IN in the locale setting during installation, the database shows datctype as en-IN and datcollversion successfully populates with a version number (like 1538.2). We began researching this discrepancy online and found claims stating that if datcollversion is empty, PostgreSQL cannot track collation changes. Furthermore, articles claim that if Windows performs a major OS upgrade, PostgreSQL will skip version mismatch checks, causing B-Tree indexes to become silently corrupted. Our Questions to the Community: 1. Is it true that if datcollversion is empty/NULL, a major Windows OS upgrade can cause text indexes to become silently corrupted without triggering any warning or error logs? 2. Why does the legacy Windows locale name (English_India.1252) leave the version column empty, while the short tag (en-IN) populates it? 3. What is the official recommended approach for a production Windows installation? Should we stop leaving the installer on [Default Locale] and explicitly force a short tag like en-IN or en-US to ensure version tracking is active? Thank you for your insights, Yashwanth Thati
