On Thu, Oct 24, 2013 at 10:51 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 10/24/2013 01:14 PM, Heikki Linnakangas wrote: >> One extra WAL record whenever a hint bit is set on a page, for the first >> time after a checkpoint. In other words, a WAL record needs to be >> written in the same circumstances as with page checksums, but the WAL >> records are much smaller as they don't need to contain a full page >> image, just the block number of the changed block. >> >> Or maybe we'll write the full page image after all, like with page >> checksums, just without calculating the checksums. It might be tricky to >> skip the full-page image, because then a subsequent change of the page >> (which isn't just a hint-bit update) needs to somehow know it needs to >> take a full page image even though a WAL record for it was already written. > > I think it would be worth estimating what this actually looks like in > terms of log write quantity. My inclication is to say that if it > increases log writes less than 10%, we don't need to provide an option > to turn it off. > > The reasons I don't want to provide a disabling GUC are: > a) more GUCs > b) confusing users > c) causing users to disable rewind *until they need it*, at which point > it's too late to enable it. > > So if there's any way we can avoid having a GUC for this, I'm for it. > And if we do have a GUC, failback should be enabled by default.
+1 on the principle. In fact I've been considering suggesting we might want to retire the difference between archive and hot_standby as wal_level, because the difference is usually so small. And the advantage of hot_standby is in almost every case worth it. Even in the archive recovery mode, being able to do pause_at_recovery_target is extremely useful. And as you say in (c) above, many users don't realize that until it's too late. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
