Tom Lane wrote:
> Heikki Linnakangas writes:
>> But we don't use tuplesort to return tuples from functions, so it's not
>> broken in a user-visible way. Unless you can think of another scenario
>> like that.
>
> (1) create a cursor whose plan involves a sort that will spill to disk
> (2) enter su
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Got it. So doesn't tuplesort have the same issue?
> Tuplesort has the same general problem that the caller of puttuple needs
> to be in the right resource owner. Which ought to be fixed, especially
> since tuplesort doesn't require that for the mem
Tom Lane wrote:
> Got it. So doesn't tuplesort have the same issue?
Tuplesort has the same general problem that the caller of puttuple needs
to be in the right resource owner. Which ought to be fixed, especially
since tuplesort doesn't require that for the memory context anymore.
But we don't us
Heikki Linnakangas writes:
> Tom Lane wrote:
>> BTW, I'm not convinced that the owner-switchery you added to pl_exec.c
>> is necessary/appropriate. Under what circumstances would that be a good
>> idea?
> A PL/pgSQL normally runs in the whatever resource owner is current when
> the function is c
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Patch against CVS HEAD to do that and fix the reported bug attached. Now
>> that the tuplestore_put* switches to the right memory context, we could
>> remove that from all the callers, but this patch only does it for pl_exec.c.
>
> BTW, I'm not conv
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I think it was just a performance optimization. It's probably not
>> measurable though; even in the in-memory case there's at least a palloc
>> inside the put() function, no?
> Yes. And many of the callers do the memory context switching dance anyw
Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Dec 22, 2009 at 11:45 AM, Heikki Linnakangas
>> wrote:
>>> AFAICS it is always a bug to be in a different memory context
>>> in tuplestore_put* than in tuplestore_begin_heap(), so it would be more
>>> robust to not put the burden on the callers.
>
Heikki Linnakangas writes:
> Patch against CVS HEAD to do that and fix the reported bug attached. Now
> that the tuplestore_put* switches to the right memory context, we could
> remove that from all the callers, but this patch only does it for pl_exec.c.
BTW, I'm not convinced that the owner-swit
Greg Stark writes:
> On Tue, Dec 22, 2009 at 11:45 AM, Heikki Linnakangas
> wrote:
>> AFAICS it is always a bug to be in a different memory context
>> in tuplestore_put* than in tuplestore_begin_heap(), so it would be more
>> robust to not put the burden on the callers.
> I thought there were co
On Tue, Dec 22, 2009 at 11:45 AM, Heikki Linnakangas
wrote:
> With regards to this bug report:
> http://archives.postgresql.org/pgsql-bugs/2009-12/msg00241.php
Hm, do we have any build farm members running with work_mem set to the minimum?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, Dec 22, 2009 at 11:45 AM, Heikki Linnakangas
wrote:
...
> AFAICS it is always a bug to be in a different memory context
> in tuplestore_put* than in tuplestore_begin_heap(), so it would be more
> robust to not put the burden on the callers.
> ...
> Patch against CVS HEAD to do that and fix
With regards to this bug report:
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00241.php
I think we should change tuplestore code so that callers of
tuplestore_put* don't need to switch to the correct memory context (and
resource owner, after this patch) before call. Instead,
tuplestore_beg
12 matches
Mail list logo
