Excerpts from Pavan Deolasee's message of lun jul 18 14:50:03 -0400 2011: > On Mon, Jul 18, 2011 at 3:14 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> > I will be happy to remove it again when we have shown there are no > > bugs.... getting this wrong is a data loss issue. > > Though I understand the fear for data loss, do we have much precedent of > adding GUC to control such mechanism ? Even for complex feature like HOT we > did not add any GUC to turn it off and I don't think we missed it. So I > would suggest we review the code and test the feature extensively and fix > the bugs if any, but lets not add any GUC to turn it off. In fact, the code > and algorithm itself is not that complex and I would suggest you to take a > look at the patch. Yeah. Having two implementations is much worse. We're going to have databases upgraded from previous versions that had the old behavior for a while and then switched (when pg_upgraded), and also databases that only have the new behavior. That's complex enough. If we add a GUC, we're going to have databases that ran with the new behavior for a while, then switched to the old one, and maybe back and forth a few times; debugging that kind of stuff is going to be "interesting" (for expensive values of interestingness). -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
