On Mon, Dec 19, 2011 at 6:10 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Throwing WARNINGs for normal events would not help anybody; thousands > of false positives would just make Postgres appear to be less robust > than it really is. That would be a credibility disaster. VMWare > already have their own distro, so if they like this patch they can use > it.
Agreed on all counts. It seems to me that it would be possible to plug this hole by keeping track of which pages in shared_buffers have had unlogged changes to them since the last FPI. When you go to evict such a page, you write some kind of WAL record for it - either an FPI, or maybe a partial page image containing just the parts that might have been changed (like all the tuple headers, or whatever). This would be expensive, of course. > The only sensible way to handle this is to change the page format as > discussed. IMHO the only sensible way that can happen is if we also > support an online upgrade feature. I will take on the online upgrade > feature if others work on the page format issues, but none of this is > possible for 9.2, ISTM. I'm not sure that I understand the dividing line you are drawing here. However, with respect to the implementation of this particular feature, it would be nice if we could arrange things so that space cost of the feature need only be paid by people who are using it. I think it would be regrettable if everyone had to give up 4 bytes per page because some people want checksums. Maybe I'll feel differently if it turns out that the overhead of turning on checksumming is modest, but that's not what I'm expecting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
