Robert Haas wrote: > That idea has the additional advantage of confusing the level of > detail of our WAL logging (minimal vs. archive vs. hot standby) with > the mechanism used to protect against torn pages (full page writes vs. > idempotent WAL records vs. prayer). When they set it wrong and > destroy their system, we can tell them it's their own fault for not > configuring the system properly! Bwahahahaha!
I love it! Create confusing configuration options and blame the user! > In all seriousness, I can't imagine that we'd make this > user-configurable in the first place, since that would amount to > having two sets of WAL records each of which would be even less well > tested than what we have now; and for a project this complex, we > probably shouldn't even consider changing things that seem to work now > unless the new system is clearly better than the old. > > > Idempotent does seem like the most promising idea. > > I tend to agree with you, but I'm worried it won't actually work out > to a win. By the time we augment the records with enough additional > information we may have eaten up a lot of the benefit we were hoping > to get. This is where I was confused. Our bad case now is when someone modifies one row on a page between checkpoints --- instead of writing 400 bytes, we write 8400. What portion of between-checkpoint activity writes more than a few rows to a page? I didn't think many, except for COPY. Ideally we could switch in and out of this mode per page, but that seems super-complicated. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
