Re: assertion failure 9.3.4
От | Andrew Dunstan |
---|---|
Тема | Re: assertion failure 9.3.4 |
Дата | |
Msg-id | 534FE1F8.2050905@dunslane.net обсуждение исходный текст |
Ответ на | Re: assertion failure 9.3.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: assertion failure 9.3.4
Re: assertion failure 9.3.4 |
Список | pgsql-hackers |
On 04/16/2014 10:28 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 04/16/2014 07:19 PM, Tom Lane wrote: >>> Yeah, it would be real nice to see a self-contained test case for this. >> Well, that might be hard to put together, but I did try running without >> pg_stat_statements and auto_explain loaded and the error did not occur. >> Not sure where that gets us in terms of deciding on a culprit. > Could we at least see the exact parameter settings for pg_stat_statements > and auto_explain? (And any other GUCs with nondefault values?) > > Here are all the settings from the run that failed: listen_addresses = '*' port = 5432 fsync = on synchronous_commit = off checkpoint_segments = 128 checkpoint_completion_target= 0.9 shared_buffers = 512MB max_connections = 300 work_mem = 128MB maintenance_work_mem= 32MB effective_cache_size = 16GB effective_io_concurrency = 2 logging_collector = on log_destination= 'stderr' log_filename = 'postgresql-%a.log' log_rotation_size = 0 log_truncate_on_rotation = on log_line_prefix = '%t [%p] %l: ' log_connections = on log_disconnections = on log_statement = 'all' track_activity_query_size= 10240 shared_preload_libraries = 'auto_explain,pg_stat_statements' As you can see, auto_explain's log_min_duration hasn't been set, so it shouldn't be doing anything very much, I should think. cheers andrew
В списке pgsql-hackers по дате отправления: