Re: Oh, this is embarrassing: init file logic is still broken - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Oh, this is embarrassing: init file logic is still broken
Date
Msg-id 20150625.172025.1041054706789821368.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Oh, this is embarrassing: init file logic is still broken  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Oh, this is embarrassing: init file logic is still broken  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On 06/23/2015 04:44 PM, Tom Lane wrote:
>> Chasing a problem identified by my Salesforce colleagues led me to the
>> conclusion that my commit f3b5565dd ("Use a safer method for determining
>> whether relcache init file is stale") is rather borked.  It causes
>> pg_trigger_tgrelid_tgname_index to be omitted from the relcache init file,
>> because that index is not used by any syscache.  I had been aware of that
>> actually, but considered it a minor issue.  It's not so minor though,
>> because RelationCacheInitializePhase3 marks that index as nailed for
>> performance reasons, and includes it in NUM_CRITICAL_LOCAL_INDEXES.
>> That means that load_relcache_init_file *always* decides that the init
>> file is busted and silently(!) ignores it.  So we're taking a nontrivial
>> hit in backend startup speed as of the last set of minor releases.
> 
> OK, this is pretty bad in its real performance effects.  On a workload
> which is dominated by new connection creation, we've lost about 17%
> throughput.

Are we going to release 9.4.5 etc. soon?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Improving log capture of TAP tests with IPC::Run
Next
From: Amit Kapila
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive