On 2022-01-18 15:15:44 -0500, Tom Lane wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rorqual&dt=2022-01-18%2019%3A50%3A57
>
> That reloptions test has been there awhile, and we weren't seeing
> issues with it before. What about the replication environment
> would cause VACUUM to behave differently? Maybe it thinks there
> are non-removable tuples because the walsender is holding back
> global xmin?
hot_standby_feedback isn't enabled, so it shouldn't...
I wonder if it's just a question of the different configuration used by
Cluster.pm, rather than the fact that a replica is actually connected.
Locally I see the following additions to the configuration for the primary in
027_stream_regres.pl
fsync = off
restart_after_crash = off
log_line_prefix = '%m [%p] %q%a '
log_statement = all
log_replication_commands = on
wal_retrieve_retry_interval = '500ms'
stats_temp_directory = 'pg_stat_tmp'
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_log_hints = on
hot_standby = on
shared_buffers = 1MB
max_connections 25
max_wal_size = 128MB
port = 63698
unix_socket_directories = '/tmp/098ygO1bAF'
listen_addresses = ''
max_prepared_transactions = 10
That's an extremely small shared_buffers for running the regression tests, it'd not
be surprising if that provoked problems we don't otherwise see. Perhaps VACUUM
ends up skipping over a page because of page contention?
Also, it's odd that there's "max_connections 25" without an equal sign. I'd
kind of expected that to cause an error....
Greetings,
Andres Freund
