Re: Transaction-lifespan memory leak with plpgsql DO blocks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Transaction-lifespan memory leak with plpgsql DO blocks
Дата
Msg-id CA+TgmoZP6dpNxcgxHi0hFtZ6qO+DAq=DiP_yR7VoTAuKe5cAQA@mail.gmail.com
обсуждение исходный текст
Ответ на Transaction-lifespan memory leak with plpgsql DO blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Transaction-lifespan memory leak with plpgsql DO blocks  (David Johnston <polobo@yahoo.com>)
Re: Transaction-lifespan memory leak with plpgsql DO blocks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Or we could say "what the heck are you doing executing tens of
> thousands of DO blocks?  Make it into a real live function;
> you'll save a lot of cycles on parsing costs."  I'm not sure that
> this is a usage pattern we ought to be optimizing for.

I'm not volunteering to spend time fixing this, but I disagree with
the premise that it isn't worth fixing, because I think it's a POLA
violation.  From the user's point of view, there are plausible reasons
for this to be slow, but there's really no reason to expect it to leak
memory.  That's a sufficiently astonishing result that it wouldn't be
surprising for this to get reported as a bug where a simple
performance gap wouldn't be, and I think if we don't fix it the
perception will be that we've left that bug unfixed.  Now, there are
lots of things we don't fix just because there is not an infinitely
large army of trained PostgreSQL hackers who love to fix other
people's bugs for free, so I'm not going to say we HAVE to fix this or
whatever - but neither do I think fixing it is useless and worthless.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Can we add sample systemd service file to git repo?
Следующее
От: Nicolas Barbier
Дата:
Сообщение: Re: Fast insertion indexes: why no developments