Re: BUG in 10.1 - dsa_area could not attach to a segment that hasbeen freed - Mailing list pgsql-bugs

From Alexander Voytsekhovskyy
Subject Re: BUG in 10.1 - dsa_area could not attach to a segment that hasbeen freed
Date
Msg-id CAPa4P2YvEH9ekkh=FPwopPerN3qxyqFsicUWcZCsz4+uVGgixw@mail.gmail.com
Whole thread Raw
In response to Re: BUG in 10.1 - dsa_area could not attach to a segment that hasbeen freed  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-bugs
Here is GDB log: Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00007f53e538e9b3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 in ../sysdeps/unix/syscall-template.S Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00005560250a10cf in ?? () Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00005560250a10cf in ?? () Continuing. Program received signal SIGUSR1, User defined signal 1. 0x0000556024ed08e3 in ?? () Continuing. Program received signal SIGUSR1, User defined signal 1. 0x0000556024ed08e3 in ?? () Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00007f53e538e9b3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 in ../sysdeps/unix/syscall-template.S Continuing. Program received signal SIGUSR1, User defined signal 1. 0x00007f53e538e9b3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 in ../sysdeps/unix/syscall-template.S Continuing. Program received signal SIGUSR1, User defined signal 1. 0x0000556024ec9896 in bringetbitmap () Detaching from program: /usr/lib/postgresql/10/bin/postgres, process 7453 On Wed, Nov 29, 2017 at 4:12 PM, Amit Kapila wrote: > On Wed, Nov 29, 2017 at 6:58 PM, Alexander Voytsekhovskyy > wrote: > > > > > > On Wed, Nov 29, 2017 at 2:38 PM, Amit Kapila > > wrote: > >> > >> On Tue, Nov 28, 2017 at 10:47 PM, Alexander Voytsekhovskyy > >> wrote: > >> > Hi, > >> > > >> > in very certain case i am getting error > >> > > >> > "ERROR: dsa_area could not attach to a segment that has been freed" > >> > > >> > >> Can you try to get call stack so that we can get a better picture of > >> what is happening here? One way could be you can change this ERROR to > >> PANIC which will generate core dump and you can get stack trace. > >> > > > > Yes, i can do both - i can reproduce it on test environment also > > > > is there somewhere manual for that? > > > > You can get some information from the below link: > https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_ > a_running_PostgreSQL_backend_on_Linux/BSD > > -- > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com >

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUGS] Improper const-evaluation of HAVING with grouping sets and subquery pullup
Next
From: Tom Lane
Date:
Subject: Re: BUG #14936: Huge backend memory usage during schema dump of database with many views