If you use ALTER ROLE/DATABASE SET to configure an invalid search_path, PostgreSQL 9.1 issues a complaint about the invalid setting on each new connection. This is a behavior change relatively to previous releases, which did not. git bisect blames this commit:
2594cf0e8c04406ffff19b1651c5a406d376657c is the first bad commit commit 2594cf0e8c04406ffff19b1651c5a406d376657c Author: Tom Lane <t...@sss.pgh.pa.us> Date: Thu Apr 7 00:11:01 2011 -0400 Revise the API for GUC variable assign hooks. The previous functions of assign hooks are now split between check hooks and assign hooks, where the former can fail but the latter shouldn't. Aside from being conceptually clearer, this approach exposes the "canonicalized" form of the variable value to guc.c without having to do an actual assignment. And that lets us fix the problem recently noted by Bernd Helmle that the auto-tune patch for wal_buffers resulted in bogus log messages about "parameter "wal_buffers" cannot be changed without restarting the server". There may be some speed advantage too, because this design lets hook functions avoid re-parsing variable values when restoring a previous state after a rollback (they can store a pre-parsed representation of the value instead). This patch also resolves a longstanding annoyance about custom error messages from variable assign hooks: they should modify, not appear separately from, guc.c's own message about "invalid parameter value". Is this an intentional change? And is it desirable? -- 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
