Re: seg fault crashed the postmaster

Поиск
Список
Период
Сортировка
От Gordon Shannon
Тема Re: seg fault crashed the postmaster
Дата
Msg-id AANLkTimcFGLUOR87_G7BtCQ2PpLvGH_FKrtt8_AiVkRy@mail.gmail.com
обсуждение исходный текст
Ответ на Re: seg fault crashed the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: seg fault crashed the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: seg fault crashed the postmaster
Следующее
От: Tom Lane
Дата:
Сообщение: Re: seg fault crashed the postmaster