On Sat, Jan 01, 2022 at 04:07:50PM -0800, Noah Misch wrote:
> On Sat, Jan 01, 2022 at 11:35:02AM -0500, Tom Lane wrote:
> > Noah Misch <noah@leadboat.com> writes:
> > > I get the same results. The leak arises because AIX freelocale() doesn't free
> > > all memory allocated in newlocale(). The following program uses trivial
> > > memory on GNU/Linux, but it leaks like you're seeing on AIX:
> >
> > Bleah.
> >
> > > If you have access to file an AIX bug, I recommend doing so. If we want
> > > PostgreSQL to work around this, one idea is to have ECPG do this newlocale()
> > > less often. For example, do it once per process or once per connection
> > > instead of once per ecpg_do_prologue().
> >
> > It's worse than that: see also ECPGget_desc(). Seems like a case
> > could be made for doing something about this just on the basis
> > of cycles expended, never mind freelocale() bugs.
>
> Agreed. Once per process seems best. I only hesitated before since it means
> nothing will free this storage, which could be annoying in the context of
> Valgrind and similar. However, ECPG already has bits of never-freed memory in
> the form of pthread_key_create() calls having no pthread_key_delete(), so I
> don't mind adding a bit more.
The comparison to pthread_key_create() wasn't completely fair. While POSIX
welcomes pthread_key_create() to fail with ENOMEM, the glibc implementation
appears not to allocate memory. Even so, I'm okay leaking one newlocale() per
process lifetime.
I had expected to use pthread_once() for the newlocale() call, but there would
be no useful way to report failure and try again later. Instead, I called
newlocale() while ECPGconnect() holds connections_mutex. See log message and
comments for details. I tested "./configure ac_cv_func_uselocale=no ..." and
tested the scenario of newlocale() failing every time.
