|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 |
|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|
|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|