On 02.09.2021 16:35, M Tarkeshwar Rao wrote:
We did a stability test for our product, where we continuously
inserting data into postgres tables. We did this for three days
continuously.
Memory utilization of our Postgres container continuously increasing.
I am not certain whether it is
On 22.06.2021 02:44, Jerry Levan wrote:
The below fails... the 'fe80' is the ip6 address of big box.
[jerry@bigbox ~]$ psql -h bigbox
psql: error: FATAL: no pg_hba.conf entry for host "fe80::fe3f:dbff:fed1:f62e%enp7s0", user
"lxxx", database "lxxx", SSL off
[...]
Netstat shows that
Hello Felix,
On 11.04.2021 02:31, felix.quin...@yahoo.com wrote:
I see no reason why ask elsewhere first, the link for the installer download is
on the Postgresql website, not elsewhere. The most logical thing to do is ask
here first.
Because it is the Postgresql installer.
Hello Tom,
On 31.03.2021 20:24, Tom Lane wrote:
Based on nearby threads, it occurs to me to ask whether you have JIT
enabled, and if so whether turning it off helps. There seems to be
a known leak of the code fragments generated by that in some cases.
That's it!
I am quite surprised that a
On 31.03.2021 20:27, Paul Ramsey wrote:
On Mar 31, 2021, at 11:24 AM, Tom Lane wrote:
If that's not it, then the leak must be accumulating through plain
old malloc calls. There's not much of that in the core backend
(although if you use ispell text search dictionaries, maybe [1] is
relevant),
On 30.03.2021 20:46, Tom Lane wrote:
Stephan Knauss writes:
The wiki suggested to dump MemoryContext states for more details, but
something strange happens when attaching gdb. It seems that the process
is immediately killed and I can no longer dump such details.
(I think the -v option
Hello,
I have a setup in which I have constantly 8 connections to the database
open which query data for map rendering. The query involve only a hand
full of tables, but could be complex and use postgis functions.
The connection stays open. Only read-requests are happening, no
