Re: Defaults for replication/backup - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Defaults for replication/backup
Date
Msg-id CABUevEzqa4GAERnuFo1XCysYuO7giarVTrAu8JoKrSw5kpHsBw@mail.gmail.com
Whole thread Raw
In response to Re: Defaults for replication/backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Defaults for replication/backup
List pgsql-hackers


On Sat, Feb 13, 2016 at 4:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> 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

It would be easier to sell this if we had some numbers for the amount of
overhead it would add for people *not* using the features.  I do not think
I've ever seen, eg, pgbench results with different wal_level and all else
the same.

That's going to be extremely workload dependent. For example, I'd expect the overhead to be very close to 0 on a pgbench SELECT only benchmark :)

The big thing is, IIRC, that we turn off the optimizations in min_wal_level. *most* people will see no impact of their regular application runtime from that, but it might definitely have an effect on data loads and such. For normal runtime, there should be very close to zero difference, no?


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

Potential security implications?


Since we already allow superuser login from that same target, I don't see any.
 

--

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Defaults for replication/backup
Next
From: Tom Lane
Date:
Subject: Re: Defaults for replication/backup