On 20 July 2017 at 15:00, Neha Sharma <neha.sha...@enterprisedb.com> wrote:
> Hi Craig, > > I had done a fresh initdb,the default parameter configuration was used. I > was setting few set of parameters while startup by the below command. > > ./postgres -d postgres -c shared_buffers=$shared_bufs -N 200 -c > min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c > maintenance_work_mem=1GB -c checkpoint_completion_target=0.9 & > > Now I have modified the script a bit with Robert's suggestion as below. > Instead of starting it with postgres binary i have set it in conf file and > starting the server with pg_ctl. I am waiting for the results,once the core > dump is generated will share the details. > Thanks. To verify that you do get a coredump, you might want to consider sending a kill -SEGV to a backend and make sure that it actually dumps core and you can find the core. Ideally you'd actually set the coredumps to include shmem (see coredump_filter in http://man7.org/linux/man-pages/man5/core.5.html), but with 8GB shared_buffers that may not be practical. It'd be very useful if possible. If this is wraparound-related, as it appears to be, you might get faster results by using a custom pgbench script for one or more workers that just runs txid_current() a whole lot. Or jump the server's xid space forward. I've got a few other things on right now but I'll keep an eye out and hope for a core dump. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services