Re: seg fault crashed the postmaster

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-56124(at)n5(dot)nabble(dot)com<ml-node%2B3323935-1680610224-56124(at)n5(dot)nabble(dot)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.