allowing wal_level change at run time - Mailing list pgsql-hackers

From Peter Eisentraut
Subject allowing wal_level change at run time
Date
Msg-id 55D31E0D.8060801@gmx.net
Whole thread Raw
Responses Re: allowing wal_level change at run time  (Magnus Hagander <magnus@hagander.net>)
Re: allowing wal_level change at run time  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
In [1], it was discussed to make wal_level changeable at run time
(PGC_SIGHUP), as part of an effort to make replication easier to set up
and/or provide better defaults.  I was wondering what it would take to
do that.

I looks like increasing the setting is doable, as long as we WAL-log the
change using existing facilities.  I don't understand the hot_standby ->
logical transition, so maybe something else is necessary there.

How would we handle decreases at run time?  We can prevent >=archive ->
minimal if archiving is running or there are physical replication slots,
and we can prevent logical -> something less if there are logical
replication slots, but AFAICT, we don't have a way to check whether
anyone currently needs level hot_standby.  (Thread [1] originally
proposed to get rid of the archive/hot_standby distinction, which would
help here.)  Or we could just let users make their own mess if they want to.

Comments?


[1]
http://www.postgresql.org/message-id/CA+TgmoZLji0tAjoVOPFAPJ8d2e8Q=ZM4ZdTQXSKA3J+z-PNi4A@mail.gmail.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Magnus Hagander
Date:
Subject: Re: allowing wal_level change at run time