From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | a(dot)zakirov(at)postgrespro(dot)ru |
Cc: | pavel(dot)stehule(at)gmail(dot)com, david(at)pgmasters(dot)net, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: IF (NOT) EXISTS in psql-completion |
Date: | 2016-03-30 05:48:15 |
Message-ID: | 20160330.144815.225518429.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
No one should care of this but to make shure..
At Tue, 29 Mar 2016 20:12:03 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20160329(dot)201203(dot)78219296(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> By the way, memory blocks that readline sees are freed by it but
> blocks allocated by the additional pstrdup seems abandoned
> without being freed. Actually, the address of newly allocated
> blocks seems increasing time by time slowly *even without this
> patch*..
psql doesn't leak memory. The increment was the result of new
history entry. src/common/exec.c does the following thing,
./common/exec.c:586: putenv(strdup(env_path));
./common/exec.c:597: putenv(strdup(env_path));
valgrind complains that the memory block allocated there is
definitely lost but it seems to be called once in lifetime of a
process.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Harshal Dhumal | 2016-03-30 06:16:56 | [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping. |
Previous Message | Tatsuo Ishii | 2016-03-30 05:15:39 | Re: multivariate statistics v14 |