On Mon, Jan 02, 2017 at 10:21:41AM +0100, Magnus Hagander wrote: > On Mon, Jan 2, 2017 at 10:17 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On 31 December 2016 at 15:00, Magnus Hagander <mag...@hagander.net> wrote: > > > max_wal_senders=10 > > > max_replication_slots=20
[...] > > > wal_level=replica > > > > This is more problematic because it changes behaviours. > > You can't actually change the other two without changing wal_level. That actually goes both ways: I recently saw a server not start cause we were experimenting with temporarily setting wal_level to minimal for initial bulk loading, but did not reduce max_wal_senders back to zero. So it failed at startup with 'FATAL: WAL streaming (max_wal_senders > 0) requires wal_level "replica" or "logical"'. I don't want to hijack this thread, but I wonder whether the name "*max*_wal_senders" really conveys that dependence on wal_level (there's no comment to that end in the postgresql.conf sample) and/or whether maybe the admin should just be notified that WAL streaming is turned off cause wal_level < 'replica'? Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers