Re: [BUGS] BUG #8573: int4range memory consumption - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] BUG #8573: int4range memory consumption
Date
Msg-id 11268.1383576322@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #8573: int4range memory consumption  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [BUGS] BUG #8573: int4range memory consumption
Re: [BUGS] BUG #8573: int4range memory consumption
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [v9.4] row level security
Next
From: Andres Freund
Date:
Subject: Re: [BUGS] BUG #8573: int4range memory consumption