Hi all, Right now, PostgresNode.pm uses this set of parameters when initializing a node: print $conf "\n# Added by PostgresNode.pm\n"; print $conf "fsync = off\n"; print $conf "restart_after_crash = off\n"; print $conf "log_line_prefix = '%m [%p] %q%a '\n"; print $conf "log_statement = all\n"; print $conf "wal_retrieve_retry_interval = '500ms'\n"; print $conf "port = $port\n";
When streaming is enabled, the following set is used: print $conf "wal_level = replica\n"; # replace by logical here is you need ;) print $conf "max_wal_senders = 5\n"; print $conf "max_replication_slots = 5\n"; print $conf "max_wal_size = 128MB\n"; print $conf "shared_buffers = 1MB\n"; print $conf "wal_log_hints = on\n"; print $conf "hot_standby = on\n"; print $conf "max_connections = 10\n"; While all those settings are good defaults in my opinion, I have been trapped by wal_keep_segments being present when designing a test. The TAP test in question here was forcing WAL segments to be recycled with two checkpoints and some forced segment switches to make a disconnected standby sync back to a primary using some archives, but then I got surprised that max_wal_size was not respected. Until I noticed that keep_wal_segments was in play. I tend to think that while all the other parameters make sense to deploy instances that need few resources, wal_keep_segments may cause up to 350MB of WAL segments to be kept in each pg_wal's instance, while max_wal_size is set at 128MB. The only test in the code tree in need of wal_keep_segments is actually pg_rewind, which enforces checkpoints after the rewind to update the source's control file. So, thoughts about the attached that reworks this portion of PostgresNode.pm? Thanks, -- Michael
tap-minimize-default.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers