Re: Improve OOM handling in pg_locale.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve OOM handling in pg_locale.c
Date: 2016-11-21 23:28:12
Message-ID: 14399.1479770892@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> writes:
> On Thu, Oct 13, 2016 at 1:40 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
>> I am attaching that to the next CF.

> One thing which you might need to reconsider is removal of memory leak
> comments. There is still a leak if there is an error while encoding in
> db_encoding_strdup.
> Unless you want to catch those error with an TRY();....CATCH(); and then
> free the mem.

I could have lived with leaving the leak there, but really this wasn't
fixing the worst problem with the code: if it did throw an error out of
the middle of that sequence, it would leave the process setlocale'd to
some other locale than we want. That could lead to unwanted behavior
in printf and other functions. And this isn't all that unlikely: an
encoding conversion failure is definitely possible if you have a locale
selected that's not compatible with the database encoding.

I whacked the patch around enough so that we didn't do anything except
libc calls between setting and restoring the locale. At that point it
was just a matter of adding a TRY block to be able to say that we
didn't leak any strdup'd strings, so I figured "might as well".

Pushed with those changes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-11-21 23:32:41 Re: Improve OOM handling in pg_locale.c
Previous Message Tom Lane 2016-11-21 22:30:09 Re: [sqlsmith] Parallel worker crash on seqscan