
28 Dec
2015
28 Dec
'15
7:56 a.m.
Hi Sergei, On Wed, Nov 25, 2015 at 02:11:21PM +0100, Sergei Golubchik wrote: > Hi, Sergey! > > On Nov 25, Sergey Vojtovich wrote: > > On Mon, Nov 23, 2015 at 10:44:39AM +0100, Sergei Golubchik wrote: > > > On Nov 23, Sergey Vojtovich wrote: > > > > On Mon, Nov 23, 2015 at 10:00:33AM +0100, Sergei Golubchik wrote: > > > > > On Nov 23, Sergey Vojtovich wrote: > > > > > > > > > > Could there be any other fix for P_S autosizing besides moving all its > > > > > dependencies to early options? > > > > No simple solution on my mind. May be initialize PFS with defaults and > > > > then reinitialize with real values? > > > > > > perfschema creates fixed-size (*) arrays based on these values. And > > > allocates data mutexes, rwlocks, conditions there. > > > > > > if perfschema data structures are re-initialized, all mutexes/etc have > > > to be. That's why Marc has created these "early options" in the > > > first place. To reinitialize only those few mutexes that my_getopt > > > needs, not half of the server. > > > > > All I can see now is 19 PFS variables depending on table_definition_cache && > > table_open_cache && max_connections && open_files_limit values. I couldn't > > easily track down further dependencies, at least number of allocated arrays > > basing on these variables is far over 19. > > > > Could you confirm that: > > 1. we want to fix PFS autosizing along with this patch > > No. > > > 2. we want to avoid early initialization of these 4 server variables and > > instead reinitialize PFS when they're autosized > > No. > > 1. PFS autosizing can be fixed later. But assuming it will be fixed, I > wouldn't want you to do a patch now that will be completely reverted > when fixing PFS autosizing. > > 2. No, why? I'm lost now: - we don't want to fix PFS autosizing along with this patch (that is we don't want to make these 4 variables early options right now) - and we don't want this patch because it will be reverted later (though I'd say not reverted, but moved because this logic will stay) This makes me think that: - either we don't want to fix this bug until PFS autosizing is fixed first - or there's another options which I can't think of What's your thinking? Thanks, Sergey