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.



Attachment: session_warning.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to