So I committed this patch without backpatching anything. There was some discussion about the exact strategy for backpatching the behavior change, but no final agreement; the suggestions were
0. Backpatch as an ERROR. If it causes failures, people is supposed to change their apps or something. 1. Don't backpatch the ERROR bit at all, so that if the renegotiation fails we would silently continue just as currently 2. Do spit the message, but only as a WARNING. Thinks this may end up causing log disks to fill up. 3. Add it as an ERROR, but make it possible to disable it, presumably via a new GUC. So people can see their security problems and hopefuly fix them, but if they don't, then they can shut it up via server configuration. This would entail a GUC variable that exists in existing branches but not HEAD (we could avoid an upgradability problem of postgresql.conf files by having a no-op phantom GUC variable in HEAD). I was reminded of this once more because I just saw a spurious renegotiation failure in somebody's production setup. Kind of like a recurring nightmare which I thought I had already erradicated. Opinions? Also, should we wait longer for the new renegotiation code to be more battle-tested? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
