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 <simon@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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
