I wonder if it'd be useful to compile with
./configure CFLAGS=-DHJDEBUG=1
On 4/16/2019 11:30, Tom Lane wrote:
Breakpoint 6, AllocSetAlloc (context=0x29a6450, size=8) at aset.c:718
718 {
(gdb) bt 8
#0 AllocSetAlloc (context=0x29a6450, size=8) at aset.c:718
#1 0x0084e8ad in palloc0 (size=size@entry=8) at mcxt.c:969
#2 0x00702b63 in
On 15/04/2019 08:23, Gunther wrote:
For weeks now, I am banging my head at an "out of memory" situation.
There is only one query I am running on an 8 GB system, whatever I
try, I get knocked out on this out of memory. It is extremely
impenetrable to understand and fix this error. I guess I
Jeff Janes writes:
> On Mon, Apr 15, 2019 at 9:49 PM Gunther wrote:
>> Isn't there some other way?
> I wonder of valgrind or something like that could be of use. I don't know
> enough about those tools to know. One problem is that this is not really a
> leak. If the query completely
On Mon, Apr 15, 2019 at 9:49 PM Gunther wrote:
> Jeff Janes had more
>
> Breakpoint 2, AllocSetAlloc (context=0x1168230, size=8272) at aset.c:715
>> 715 {
>> (gdb) p context->name
>> $8 = 0x96ce5b "ExecutorState"
>>
>>
> I think that the above one might have been the one you wanted.
>
> Not
On Tue, Apr 16, 2019 at 05:41:31PM +, Daulat Ram wrote:
> postgres=# \l
> kb_rep| postgres | UTF8 | C.UTF-8 | C.UTF-8 |
> postgres@b06a42b503e9:/$ pg_restore -h 10.29.50.21 -p 5432 -d kb_rep -v
> /var/lib/kb_rep_backup16
> pg_restore: [archiver (db)] connection to database "kb_rep"
Hello team,
We have a postgres11.2 on docker and we are migrating a kb_rep database from
postgres 9.6 to postgres 11.2 via pg_dump/pg_restore
We have created a kb_rep schema in postgres 11.2 also but during pg_restore
there is an error "pg_restore: [archiver (db)] connection to database
Gunther writes:
> And there we go:
> Breakpoint 6, AllocSetAlloc (context=0x29a6450, size=8) at aset.c:718
> 718 {
> (gdb) bt 8
> #0 AllocSetAlloc (context=0x29a6450, size=8) at aset.c:718
> #1 0x0084e8ad in palloc0 (size=size@entry=8) at mcxt.c:969
> #2 0x00702b63 in
It is confirmed, these two call paths are the only ones. At least
probably the only ones to occur with enough of a frequency.
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
28576 postgres 20 0 2695304 1.0g 200764 R 11.3 13.8 4:20.13 postgres:
postgres
