Re: Defaults for replication/backup

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Defaults for replication/backup
Дата
Msg-id CABUevEzqa4GAERnuFo1XCysYuO7giarVTrAu8JoKrSw5kpHsBw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Defaults for replication/backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Defaults for replication/backup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Defaults for replication/backup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Defaults for replication/backup