Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls
Дата
Msg-id 5245E2F3.7040409@vmware.com
обсуждение исходный текст
Ответ на Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls  (Nicholas White <n.j.white@gmail.com>)
Список pgsql-hackers
On 27.09.2013 14:12, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 4:20 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com>  wrote:
>> But how do we ensure that the BMS is allocated in a context?  You'd have
>> to switch contexts each time you call bms_add_member.  I don't have a
>> good answer to this.
>
> The coding of bms_add_member is pretty funky.  Why doesn't it just
> repalloc() the input argument if it's not big enough?  If it did that,
> the new allocation would be in the same memory context as the original
> one, and we'd not need to care about the memory context when adding an
> element to an already non-empty set.
>
> But even if we did decide to switch memory contexts on every call, it
> would still be much cleaner than this.  It's only three lines of code
> (and about as many instructions) to save and restore
> CurrentMemoryContext.

[looks] Huh, yeah, as it stands, bms_add_member() is an accident waiting 
to happen. It's totally non-obvious that it might cause the BMS to jump 
from another memory context to CurrentMemoryContext. Same with 
bms_add_members(). And it would be good to Assert in bms_join that both 
arguments are in the same from MemoryContext.

Let's fix that...

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Minmax indexes
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [PERFORM] Cpu usage 100% on slave. s_lock problem.