On Mon, Mar 18, 2013 at 06:24:37PM +0000, Simon Riggs wrote: > On 18 March 2013 17:52, Bruce Momjian <br...@momjian.us> wrote: > > On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote: > >> As long as the feature is off by default, so that people have to > >> turn it on to hit the biggest changed code paths, the exposure to > >> potential bugs doesn't seem too bad. New WAL data is no fun, but > >> it's not like this hasn't happened before. > > > > With a potential 10-20% overhead, > > ... for some workloads. > > > > I am unclear who would enable this at initdb time. > > Anybody that cares a lot about their data. > > > I assume a user would wait until they suspected corruption to turn it > > on, and because it is only initdb-enabled, they would have to > > dump/reload their cluster. The open question is whether this is a > > usable feature as written, or whether we should wait until 9.4. > > When two experienced technical users tell us this is important and > that they will use it, we should listen. > > > > In fact, this feature is going to need > > pg_upgrade changes to detect from pg_controldata that the old/new > > clusters have the same checksum setting. > > I don't see any way they can differ. > > pg_upgrade and checksums don't mix, in this patch, at least.
Jeff has already addressed the issue in the patch, e.g. if someone initdb's the new cluster with checksums. I am now fine with the patch based on the feedback I received. I needed to hear that the initdb limitation and the new performance numbers still produced a useful feature. -- 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
