On 04/16/2014 10:28 PM, Tom Lane wrote:
Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
