Re: seg fault crashed the postmaster - Mailing list pgsql-general

From Gordon Shannon
Subject Re: seg fault crashed the postmaster
Date
Msg-id AANLkTimcFGLUOR87_G7BtCQ2PpLvGH_FKrtt8_AiVkRy@mail.gmail.com
Whole thread Raw
In response to Re: seg fault crashed the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: seg fault crashed the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
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] <[hidden email]> 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: Re: seg fault crashed the postmaster
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: seg fault crashed the postmaster
Next
From: Tom Lane
Date:
Subject: Re: seg fault crashed the postmaster