pgsql: Plug more memory leaks when reloading config file.

Started by Robert Haasover 12 years ago3 messagescomitters
Jump to latest
#1Robert Haas
robertmhaas@gmail.com

Plug more memory leaks when reloading config file.

Commit 138184adc5f7c60c184972e4d23f8cdb32aed77d plugged some but not
all of the leaks from commit 2a0c81a12c7e6c5ac1557b0f1f4a581f23fd4ca7.
This tightens things up some more.

Amit Kapila, per an observation by Tom Lane

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/a5bca4ef034f71175d46462963af2329d22068c2

Modified Files
--------------
src/backend/utils/misc/guc-file.l | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Robert Haas (#1)
Re: pgsql: Plug more memory leaks when reloading config file.

Robert Haas <rhaas@postgresql.org> writes:

Plug more memory leaks when reloading config file.

Hm, not too sure about this hunk:

ereport(LOG,
(errmsg("skipping missing configuration file \"%s\"",
abs_path)));
- return OK;
+ OK = true;
+ goto cleanup;
}

That's changing the semantics, no? That is, what if OK was previously
false? Seems like this coding might be masking an intended failure
report. I'd have expected just "goto cleanup" without changing OK.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

#3Robert Haas
robertmhaas@gmail.com
In reply to: Tom Lane (#2)
Re: pgsql: Plug more memory leaks when reloading config file.

On Tue, Jan 21, 2014 at 11:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <rhaas@postgresql.org> writes:

Plug more memory leaks when reloading config file.

Hm, not too sure about this hunk:

ereport(LOG,
(errmsg("skipping missing configuration file \"%s\"",
abs_path)));
- return OK;
+ OK = true;
+ goto cleanup;
}

That's changing the semantics, no? That is, what if OK was previously
false? Seems like this coding might be masking an intended failure
report. I'd have expected just "goto cleanup" without changing OK.

Good catch, sorry about that.

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

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers