The number of matching rows on these queries is anything from 0 to 10000. I don't think I can tell how many would have matched on the ones that crashed. Although I suspect it would have been toward the 10000 end. I've been trying to get a reproducable test case with no luck so far.
I assume you can now see the plan? I uploaded it twice, once via gmail and once on Nabble. Here are all the non-default settings: > listen_addresses = '*' > max_connections = 450 > authentication_timeout = 20s > shared_buffers = 18GB > work_mem = 200MB > maintenance_work_mem = 8GB > shared_preload_libraries = 'auto_explain' > wal_level = hot_standby > synchronous_commit = off > wal_buffers = 8MB > commit_siblings = 1 > checkpoint_segments = 256 > checkpoint_warning = 5min > archive_mode = on > archive_command = 'cp %p /var/lib/pgsql/wal/%f.wrk; mv /var/lib/pgsql/wal/%f.wrk /var/lib/pgsql/wal/%f' > max_wal_senders = 1 > cpu_tuple_cost = 0.003 > cpu_index_tuple_cost = 0.001 > cpu_operator_cost = 0.0005 > effective_cache_size = 52GB > default_statistics_target = 200 > log_directory = '/var/log/postgres' > log_filename = 'pg%d.log' > log_min_duration_statement = 7min > log_line_prefix = '%p %u %r %t [%l]' > log_lock_waits = on > log_temp_files = 0 > track_functions = pl # none, pl, all > log_autovacuum_min_duration = 5min > autovacuum_vacuum_scale_factor = 0.1 > autovacuum_analyze_scale_factor = 0.03 > autovacuum_freeze_max_age = 1500000000 # 1,500,000,000 > autovacuum_vacuum_cost_delay = -1 > temp_tablespaces = 'ts03,ts04,ts05,ts06,ts07,ts08,ts09,ts10,ts11,ts12,ts13,ts14,ts15,ts16,ts17,ts18,ts19,ts20,ts21,ts22,ts23,ts24,ts25,ts26,ts27,ts28,ts29,ts30,ts31,ts32,ts33,ts34,ts35,ts36,ts37,ts38' > vacuum_freeze_min_age = 500000000 # 500,000,000 > vacuum_freeze_table_age = 1300000000 # 1,300,000,000 > bytea_output = 'escape' > deadlock_timeout = 5s > standard_conforming_strings = on > custom_variable_classes = 'auto_explain' > auto_explain.log_min_duration = -1 # Remember this means for everybody! > auto_explain.log_analyze = off ## DANGER! Don't set log_analyze to true unless you know what you're doing! > auto_explain.log_verbose = off > auto_explain.log_nested_statements = on On Fri, Dec 31, 2010 at 2:49 PM, Tom Lane-2 [via PostgreSQL] < ml-node+3323935-1680610224-56...@n5.nabble.com<ml-node%2b3323935-1680610224-56...@n5.nabble.com> > wrote: > > So I'm pretty sure that what we're dealing with is a case of the plan > freeing a transient tuple datum sooner than it should. But the toy case > I tried here didn't fail, so evidently I'm not close enough to the plan > you're actually using. Still need to see that EXPLAIN output. It'd be > helpful also to know what nondefault configuration settings you're > using, especially work_mem and planner-related settings. Also, do you > have an idea of how many rows might've matched the WHERE conditions? > > > -- View this message in context: http://postgresql.1045698.n5.nabble.com/seg-fault-crashed-the-postmaster-tp3323117p3323959.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
