Re: [BUGS] BUG #14531: server process (PID 12714) was terminated bysignal 11: Segmentation fault
От | NAVEEN CHALIMETI |
---|---|
Тема | Re: [BUGS] BUG #14531: server process (PID 12714) was terminated bysignal 11: Segmentation fault |
Дата | |
Msg-id | CAJ5kcKeOVTO4X6aVzB74FBAPNnCfTkUwJxR0JizKa7jxWdA6Eg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #14531: server process (PID 12714) was terminated by signal 11: Segmentation fault
|
Список | pgsql-bugs |
Thanks for your reply firstly.
I did not mention anything about logs thinking the back trace would be enough to solve the issue. Sorry for that.
I have enabled the log_statement=all already and each time it gives different queries. But until now i have seen postmaster crashed during SELECT query.
Eg: Crashed yesterday while executing query [PID] 11221 DETAIL: Failed process was running: select n.nspname, c.relname, a.attname, a.atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid, pg_get_expr(d.adbin, d.adrelid), case t.typtype when 'd' then t.typbasetype else 0 end, t.typtypmod, c.relhasoids from (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace n on n.oid = c.relnamespace and c.oid = 19175) inner join pg_catalog.pg_attribute a on (not a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d on a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order by n.nspname, c.relname, attnum
For your Information the previous query in the log is "select COLUMN_VALUE from TABLE_NAME where COLUMN_VALUE=3"
The crash is reproducible with different queries.
Previous crashed query(just format) log:- select column1,column2, column3 from table_name where column4>-1
Regards,
Naveen Ch.
On Tue, Feb 7, 2017 at 8:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
naveenallin@gmail.com writes:
> We are facing frequent crash issue in postgresql due to segmentation fault.
> We have tried various ways to debug the issue such as enabling debug level
> log etc., but we could not get any idea what is the reason behind the crash.
The postmaster should at least have logged what statement a crashed
backend was running (assuming you've not disabled the statistics
subsystem). Is there any consistency to that? It might be worth
turning on full statement logging (log_statement=all) so that you
can see everything the crashed sessions did.
The backtrace you show doesn't look much like any known 9.6 bug,
so we'd be very interested if you can put together a reproducible
test case.
regards, tom lane
В списке pgsql-bugs по дате отправления: