Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Дата
Msg-id CA+TgmoYLj89MH3YQEmuDxpC+K7y5Ydq80LC0_x6MC+6QwNqPNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations  ("MauMau" <maumau307@gmail.com>)
Ответы Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Aug 8, 2014 at 10:30 AM, MauMau <maumau307@gmail.com> wrote:
> I've tracked down the real root cause.  The fix is very simple.  Please
> check the attached one-liner patch.
>
> I confirmed that the fix is already in 9.3 and 9.5devel, so I just copied
> the code fragment from 9.5devel to 9.2.9.  The attached patch is for 9.2.9.
> I didn't check 9.4 and other versions.  Why wasn't the fix applied to 9.2?

It was considered a performance improvement - i.e. a feature - rather
than a bug fix, so it was only added to master.  That was after the
release of 9.2 and before the release of 9.3, so it's in newer
branches but not older ones.

Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master Release: REL9_3_BR [c9d7dbacd] 2013-01-29 10:43:33 +0200
   Skip truncating ON COMMIT DELETE ROWS temp tables, if the transaction hasn't   touched any temporary tables.
   We could try harder, and keep track of whether we've inserted to any temp   tables, rather than accessed them, and
whichtemp tables have been inserted   to. But this is dead simple, and already covers many interesting scenarios.
 

I'd support back-porting that commit to 9.1 and 9.2 as a fix for this
problem.  As the commit message says, it's dead simple.

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



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

Предыдущее
От: "Tomas Vondra"
Дата:
Сообщение: failures on barnacle (CLOBBER_CACHE_RECURSIVELY) because of memory leaks
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: Proposal: Incremental Backup