Re: pgsql/src/backend/postmaster (postmaster.c)
От
Peter Eisentraut
Тема
Re: pgsql/src/backend/postmaster (postmaster.c)
Дата
Msg-id
Pine.LNX.4.21.0007031845340.355-100000@localhost.localdomain
Ответ на
Список
Дерево обсуждения
pgsql/src/backend/postmaster (postmaster.c) Tom Lane <tgl>
RE: pgsql/src/backend/postmaster (postmaster.c) "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: pgsql/src/backend/postmaster (postmaster.c) Tom Lane <tgl@sss.pgh.pa.us>
RE: pgsql/src/backend/postmaster (postmaster.c) "Hiroshi Inoue" <Inoue@tpf.co.jp>
Re: pgsql/src/backend/postmaster (postmaster.c) Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql/src/backend/postmaster (postmaster.c) eisentrp@csis.gvsu.edu
Re: pgsql/src/backend/postmaster (postmaster.c) Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql/src/backend/postmaster (postmaster.c) Peter Eisentraut <peter_e@gmx.net>
Tom Lane writes: > OK, do you want to fix it, or shall I? I will. I got some half-finished code lying around that touches that. > BTW, it is now possible for guc.c to use palloc in TopMemoryContext, > if you want to do that. There's no real functional difference between > that and malloc --- except that MemoryContextStats() could include > the space used by guc.c --- but if it's just irritating you to use > malloc then you could change it. Well, I would really like a way to register an entire memory context to be swept away by elog(ERROR). But that's probably too specialized. But yes, I will look into that. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-committers по дате отправления
От: Peter Eisentraut - PostgreSQL
Дата: