AW: BUG #15641: Autoprewarm worker fails to start on Windows with huge pages in use Old PostgreSQL community/pgsql-bugs x

From: "Hans Buschmann" <buschmann(at)nidsa(dot)net>
To: "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com>, "PostgreSQL mailing lists" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: AW: BUG #15641: Autoprewarm worker fails to start on Windows with huge pages in use Old PostgreSQL community/pgsql-bugs x
Date: 2019-02-20 16:17:08
Message-ID: D2B9F2A20670C84685EF7D183F2949E202569F1C@gigant.nidsa.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


Thank you for taking a look.

I encountered this problem after switching the production system and then found it also on the new created replica.

I have no knowledge of the shared memory areas involved.

I did some further investigation and tried to reproduce it on the old System (WS2016, PG 11.2) but there it worked fine (without and with huge pages activated!).

Even on a developer machine under WS2019, PG 11.2 the error did not occur (both cases running on different generation of intel machines, Haswell and Nehalem, under different Hypervisors, WS2012R2 and WS2019).

I am really confused to not being able to reproduce the error outside of production and replica instances...

The error caused a massive flood of the logs (about 800 MB in about 1 day, on SSD)

I'll try to investigate further by configuring a second replica tomorrow, using the configuration of the production system as done per pg_basebackup.

I looked at the non-default configuration settings but could not identify anything special.

Here is a current list of the production System having 4GB of memory allocated to the VM.
(all values with XXX are a little obfuscated).

Here, to avoid the error, pg_prewarm.autoprewarm is off!

name | current_setting |
-------------------------------+--------------------------------------------+
application_name | psql |
archive_command | copy "xxxxxx" |
archive_mode | on |
auto_explain.log_analyze | off |
auto_explain.log_min_duration | -1 |
client_encoding | WIN1252 |
cluster_name | XXX_PROD |
data_checksums | on |
DateStyle | ISO, DMY |
default_text_search_config | pg_catalog.german |
dynamic_shared_memory_type | windows |
effective_cache_size | 8GB |
lc_collate | C |
lc_ctype | German_Germany.1252 |
lc_messages | C |
lc_monetary | German_Germany.1252 |
lc_numeric | German_Germany.1252 |
lc_time | German_Germany.1252 |
listen_addresses | * |
log_destination | stderr |
log_directory | <XXX_PATH_TO_LOG) |
log_file_mode | 0640 |
log_line_prefix | XXX PRD %t %i %e %2l:> |
log_statement | mod |
log_temp_files | 0 |
log_timezone | CET |
logging_collector | on |
maintenance_work_mem | 128MB |
max_connections | 200 |
max_stack_depth | 2MB |
max_wal_size | 1GB |
min_wal_size | 80MB |
pg_prewarm.autoprewarm | off |
pg_stat_statements.max | 8000 |
pg_stat_statements.track | all |
random_page_cost | 1 |
search_path | public, archiv, ablage, admin |
server_encoding | UTF8 |
server_version | 11.2 |
shared_buffers | 768MB |
shared_preload_libraries | auto_explain,pg_stat_statements,pg_prewarm |
temp_buffers | 32MB |
TimeZone | CET |
transaction_deferrable | off |
transaction_isolation | read committed |
transaction_read_only | off |
update_process_title | off |
wal_buffers | 16MB |
wal_compression | on |
wal_segment_size | 16MB |
work_mem | 64MB |
(51 Zeilen)

Thanks

Hans Buschmann

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-20 16:24:17 Re: Row Level Security − leakproof-ness and performance implications
Previous Message Chapman Flack 2019-02-20 16:16:51 Re: list append syntax for postgresql.conf

Browse pgsql-bugs by date

  From Date Subject
Next Message Joe Conway 2019-02-20 17:01:47 Re: BUG #15646: Inconsistent behavior for current_setting/set_config
Previous Message PG Bug reporting form 2019-02-20 16:10:56 BUG #15646: Inconsistent behavior for current_setting/set_config