On Mon, Oct 1, 2012 at 2:28 PM, Selena Deckelmann <sel...@chesnok.com> wrote: > On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann <sel...@chesnok.com> wrote: >> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Selena Deckelmann <sel...@chesnok.com> writes: >>>> The check_temp_buffers() problem seems like a regression and blocks us >>>> from upgrading to 9.2. The use case are functions that set >>>> temp_buffers and occasionally are called in a series from a parent >>>> session. The work around is... a lot of work. >>> >>> Uh ... how is that a regression? AFAIK it's been that way right along. >> >> We're running 9.0 - looks like it changed in 9.1, last revision to the >> relevant line was 6/2011. The group decided not to upgrade to 9.1 last >> year, but was going to just go directly to 9.2 in the next few weeks. > > And, I was basing the regression comment on the documentation for > temp_buffers: "The setting can be changed within individual sessions, > but only before the first use of temporary tables within the session; > subsequent attempts to change the value will have no effect on that > session." This statement has been there since at least 8.1. > > A warning, and then not failing seems more appropriate than an error, > given the documented behavior.
I tried out a few things, and then realized that perhaps just adding PGC_S_SESSION to the list of sources that are at elevel WARNING partially fixes this. This doesn't fix the issue with log_statement_stats, but it makes the behavior of temp_buffers the documented behavior (no longer errors out in a transaction), while still warning the user. -selena -- http://chesnok.com
session_warning.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
