Re: [BUGS] BUG #8573: int4range memory consumption
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #8573: int4range memory consumption |
Дата | |
Msg-id | 11268.1383576322@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #8573: int4range memory consumption (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [BUGS] BUG #8573: int4range memory consumption
Re: [BUGS] BUG #8573: int4range memory consumption |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-11-02 15:29:36 -0400, Tom Lane wrote: >> Attached is a proposed patch for this. It fixes most of the functions >> in printtup.c to use a per-row memory context. (I did not bother to >> fix debugtup(), which is used only in standalone mode. If you're doing >> queries large enough for mem leaks to be problematic in standalone mode, >> you're nuts.) > FWIW, by that definition I have been nuts several time in the past - > without much choice since I was recovering data from a corrupted cluster > and the database couldn't be started normally. This now has gotten worse > (even in the backbranches) since debugtup won't clean up detoasted data > anymore. > But I guess the solution for that is to use COPY in those situations > which shouldn't have that problem and should work. Also, easier to parse ;) Considering the output from debugtup goes to stdout where it will be intermixed with prompts etc, I'd have to think that COPY is a way better solution for dealing with bulk data. Really I'd like to see standalone mode, in its current form, go away completely. I had a prototype patch for allowing psql and other clients to interface to a standalone backend. I think getting that finished would be a way more productive use of time than improving debugtup. regards, tom lane
В списке pgsql-hackers по дате отправления: