On 02/04/2015 06:48 AM, Robert Haas wrote: > Anyway, I'm not talking about deriving the GUC, I'm talking about > deriving the WAL level which is currently controlled solely by the > GUC. We do something like this for full-page writes. Even if you in > general have full_page_writes=off, trying to take a hot backup forces > it on. This is smart. I think we could do something similar for > replication & hot backup. Suppose we remove the wal_level GUC > altogether, but there's a control file property that indicates whether > replication (broadly construed to include hot backup and PITR) is > enabled. Actually, more specifically, we store an LSN. If it's 0, > replication features are disabled; if it's the location of the > previous checkpoint, we're in the process of enabling replication > features; if it precedes the location of the previous checkpoint, > replication features are enabled. > > Then, we add a command like this: > > ALTER SYSTEM REPLICATION ENABLE; > > When you do that, it sets the LSN in the control file to the location > of the most recent checkpoint, and then triggers a checkpoint. When > the checkpoint is complete, it returns. You can shut it off again by > saying: > > ALTER SYSTEM REPLICATION DISABLE;
This would be awesome, and a huge step forward in usability. Question, though: do we want to distinguish between "hot_standby" and "logical" levels? Does this depend on anything other than the WAL log volume/speed? If not, we can do some tests. If Robert's suggestion proves prohibitively difficult, I also +1 the idea of not having a user-visible wal_level setting at all. Specifically, I'd love the following behavior: if logical_replication_slots > 0 wal_level = logical elif max_wal_senders > 0 wal_level = hot_standby elif archiving = on wal_level = archive (or hot_standby) else wal_level = minimal Given that this decision tree is the only possible decision tree, it makes you kind of wonder why we have an explicit GUC in the first place. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers