On Sat, Jul 02, 2022 at 11:59:58PM -0400, Tom Lane wrote:
> Confirmed that either initializing ecpg_clocale or adding -fno-common
> allows the ecpglib build to succeed. (Testing it beyond that would
> require another hour or so to build the rest of the system, so I won't.)
>
> As I said, I was al
I wrote:
> On it now, but it'll take a few minutes :-(
Confirmed that either initializing ecpg_clocale or adding -fno-common
allows the ecpglib build to succeed. (Testing it beyond that would
require another hour or so to build the rest of the system, so I won't.)
As I said, I was already leanin
Noah Misch writes:
> On Sat, Jul 02, 2022 at 11:37:08PM -0400, Tom Lane wrote:
>> Do you want me to test it on prairiedog?
> Sure, if it's easy enough. If not, I'm 87% sure it will suffice.
On it now, but it'll take a few minutes :-(
regards, tom lane
On Sat, Jul 02, 2022 at 11:37:08PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Thanks for reviewing. Pushed with that comment. prairiedog complains[1]:
> > ld: common symbols not allowed with MH_DYLIB output format with the
> > -multi_module option
> > connect.o definition of common _ec
Noah Misch writes:
> Thanks for reviewing. Pushed with that comment. prairiedog complains[1]:
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> connect.o definition of common _ecpg_clocale (size 4)
Blah.
> I bet this would fix it:
> -locale_t
On Sat, Jul 02, 2022 at 02:53:34PM -0400, Tom Lane wrote:
> This looks solid to me. The only nit I can find to pick is that I'd
> have added one more comment, along the lines of
>
> diff --git a/src/interfaces/ecpg/ecpglib/connect.c
> b/src/interfaces/ecpg/ecpglib/connect.c
> index 9f958b822c..9
Noah Misch writes:
> 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 "./conf
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 writes:
> > > I get the same results. The leak arises because AIX freelocale() doesn't
> > > free
> > > all memory allocated in newlocale(). The following progr
Le ven. 25 mars 2022, 14:25, Tom Lane a écrit :
> Guillaume Lelarge writes:
> > Did this get anywhere? Is there something we could do to make this move
> > forward?
>
> No. Write a patch?
>
I wouldn't have asked if I could write such a patch :-)
Guillaume Lelarge writes:
> Did this get anywhere? Is there something we could do to make this move
> forward?
No. Write a patch?
regards, tom lane
Le dim. 2 janv. 2022 à 01:07, Noah Misch a écrit :
> On Sat, Jan 01, 2022 at 11:35:02AM -0500, Tom Lane wrote:
> > Noah Misch writes:
> > > I get the same results. The leak arises because AIX freelocale()
> doesn't free
> > > all memory allocated in newlocale(). The following program uses
> tr
On Sat, Jan 01, 2022 at 11:35:02AM -0500, Tom Lane wrote:
> Noah Misch 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 seei
Noah Misch 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 recommen
On Wed, Dec 15, 2021 at 04:20:42PM +0100, Benoit Lobréau wrote:
> * with LDR_CNTRL=MAXDATA=0x1000, we reach 256Mo but there is no
> segfault, the program just continues running ;
> * with LDR_CNTRL=MAXDATA=0x8000, we reach 2Go and there is no segfault
> either, the program just continues ru
Our client confirmed that the more he fetches the more memory is consumed.
The segfault was indeed caused by the absence of LDR_CNTRL.
The tests show that:
* without LDR_CNTRL, we reach 256Mb and segfault ;
* with LDR_CNTRL=MAXDATA=0x1000, we reach 256Mo but there is no
segfault, the program
Hi,
(I work with Guillaume on this case.)
On Sun, Dec 12, 2021 at 8:34 AM Noah Misch wrote:
> That almost certainly means he's using a 32-bit binary with the default
> heap
> size. To use more heap on AIX, build 64-bit or override the heap size.
> For
> example, "env LDR_CNTRL=MAXDATA=0x80
On Fri, Dec 10, 2021 at 03:40:50PM +0100, Guillaume Lelarge wrote:
> After some time, the client
> crashes with a segfault error. According to him, it consumed around 256MB.
> What's weird is that it works great on Linux, but crashed on AIX.
That almost certainly means he's using a 32-bit binary w
Le sam. 11 déc. 2021 à 07:52, Justin Pryzby a écrit :
> On Fri, Dec 10, 2021 at 03:40:50PM +0100, Guillaume Lelarge wrote:
> > Hello,
> >
> > Our customer thinks he has found a memory leak on ECPG and AIX.
> >
> > The code is quite simple. It declares a cursor, opens it, and fetches the
> > only
On Fri, Dec 10, 2021 at 03:40:50PM +0100, Guillaume Lelarge wrote:
> Hello,
>
> Our customer thinks he has found a memory leak on ECPG and AIX.
>
> The code is quite simple. It declares a cursor, opens it, and fetches the
> only line available in the table many times. After some time, the client
19 matches
Mail list logo
