Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) - Mailing list pgsql-bugs

From Sandro Santilli
Subject Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Date
Msg-id 20140318170401.GE29859@localhost
Whole thread Raw
Responses Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
List pgsql-bugs
On Wed, Feb 26, 2014 at 04:01:13PM +0100, Sandro Santilli wrote:
> On Fri, Feb 21, 2014 at 08:17:36PM -0500, Tom Lane wrote:
> > I wrote:
> > > Craig Ringer <craig@2ndquadrant.com> writes:
> > >> So I'd like to confirm that this issue doesn't affect 9.1.
> >
> > > It doesn't.  I suspect it has something to do with 173e29aa5 or one
> > > of the nearby commits in backend/regex/.
> >
> > Indeed, git bisect fingers that commit as introducing the problem.
>
> Is there anything I can do for this to not fade to oblivion ?
> Will a mail to pgsql-bugs help ?

Tom: I saw you pushed a fix for the interruptability with this:
https://github.com/postgres/postgres/commit/f5f21315d25ffcbfe7c6a3fa6ffaad54d31bcde0

But we also noticed a memory leak in the regepx_replace call, did you notice
that in your tests ? Same regexp as reported. Do you need another testcase ?

--strk;

 ()  ASCII ribbon campaign  --  Keep it simple !
 /\  http://strk.keybit.net/rants/ascii_mails.txt

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #9616: Materialized view with indexes unable to load from pg_dump
Next
From: Fujii Masao
Date:
Subject: Re: BUG #9118: WAL Sender does not disconnect replication clients during shutdown