Defaults for replication/backup - Mailing list pgsql-hackers

From Magnus Hagander
Subject Defaults for replication/backup
Date
Msg-id CABUevEwfV7zDutescm2PHGvsJdYA0RWHFMTRGhwrJPGgSbzZDQ@mail.gmail.com
Whole thread Raw
Responses Re: Defaults for replication/backup
Re: Defaults for replication/backup
List pgsql-hackers
I know we've had many discussions about the defaults, so hey, let's bring out the paint-cans and do the bikeshed all over again.

I would suggest a couple of changes to the default values in parameters related to backup and replication.

The reason for this is to make it "easier to do the right thing by default", meaning the defaults should be more suitable for new users to use our tools in the default config.

Yes, these changes will increase some of the default overhead. My argument against that is that anybody who actually cares about that overhead is going to be tuning their database *anyway*, so they can just change things back to the old defaults.

So, I suggest the following changes to the defaults:

wal_level=hot_standby
max_wal_senders=10
max_replication_slots=10

And in pg_hba.conf, we enable the replication connections by default for the superuser on local/localhost.

This will make it possible to actually take a proper backup (not just a dump) off a default config cluster without having to do a restart first. And it allows you to set up archiving with pg_receivexlog for full PITR.

I think the overhead of the two max parameters is really small, but they're both dependent on the default wal_level. Yes, we've discussed it before. I think it's time to make the change now.

I'm sure there are many more settings we could discuss the defaults for, but this particular biikeshed is mine so I get to decide the initial borders, even if I don't get to decide the colors :P

--

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Small PATCH: check of 2 Perl modules
Next
From: Michael Paquier
Date:
Subject: Re: extend pgbench expressions with functions