Re: setting per-database/role parameters checks them against wrong context

From: Selena Deckelmann <selena(at)chesnok(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: setting per-database/role parameters checks them against wrong context
Date: 2012-10-01 21:28:45
Message-ID: CAN1EF+xkjdfKzRVZ=9LsQsPy_hbVZyh0r=mgwOUWjDgysU1K6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann <selena(at)chesnok(dot)com> wrote:
> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Selena Deckelmann <selena(at)chesnok(dot)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.

-selena

--
http://chesnok.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hitoshi Harada 2012-10-01 22:30:09 date_in and buffer overrun
Previous Message scc 2012-10-01 20:50:29 Re: moving system catalogs to another tablespace