Re: pgsql: Test replay of regression tests, attempt II.

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