Hi, Sergey!

On Nov 23, Sergey Vojtovich wrote:

...

On Mon, Nov 23, 2015 at 08:39:23AM +0100, Sergei Golubchik wrote:

...

On Nov 20, Sergey Vojtovich wrote:

...

revision-id: a1ab4314d1f88fa954a774c322709822d7b95344 (mariadb-10.1.8-58-ga1ab431) parent(s): cfc135b645db5fa78b9f63b1959ea3f2be137a26 committer: Sergey Vojtovich timestamp: 2015-11-20 17:32:26 +0400 message:

MDEV-7261 - Backport the default autosized value of "table_definition_cache" from MySQL 5.6.8+

Fixed table_definition_cache auto-sizing. Note that this patch doesn't address broken PFS auto-sizing.

Do you plan to address it after you've broken it? How? PFS autosizing relies on table_definition_cache, table_open_cache, max_connections, open_files_limit.

The only options that is autosized prior to PFS autosizing was table_defintion_cache. Even this option was autosized incorrectly.

So I didn't break it, it was broken even prior to this patch. In 5.7 all these options are marked EARLY and are autosized before PFS autosizing.

That's what I was getting at, yes :)

Perhaps you fix should've been to move table_definition_cache to "early options" instead of moving autosizing after normal options are initialized. At least, that's the only fix that I see, because you cannot auto-size P_S variables late. It was moved because table_definition_cache depends on table_open_cache and

Hi Sergei, On Mon, Nov 23, 2015 at 09:21:44AM +0100, Sergei Golubchik wrote: they further depend on max_connections and open_files_limit. So I'll have to move all of the above to "early options". It shouldn't be that complex, but it's a bit out of the scope of this particular bug. And I initially attempted to keep it simple. Thanks, Sergey

Hi Sergei, On Mon, Nov 23, 2015 at 10:00:33AM +0100, Sergei Golubchik wrote:

Hi, Sergey!

On Nov 23, Sergey Vojtovich wrote:

...

...

...

So I didn't break it, it was broken even prior to this patch. In 5.7 all these options are marked EARLY and are autosized before PFS autosizing.

That's what I was getting at, yes :)

Perhaps you fix should've been to move table_definition_cache to "early options" instead of moving autosizing after normal options are initialized. At least, that's the only fix that I see, because you cannot auto-size P_S variables late. It was moved because table_definition_cache depends on table_open_cache and they further depend on max_connections and open_files_limit. So I'll have to move all of the above to "early options".

It shouldn't be that complex, but it's a bit out of the scope of this particular bug. And I initially attempted to keep it simple.

I'm all for keeping it simple. But it's "as simple as possible, but not simpler than that" :)

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?

Regards, Sergey

Hi, Sergey!

On Nov 23, Sergey Vojtovich 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

On Mon, Nov 23, 2015 at 10:00:33AM +0100, Sergei Golubchik wrote: 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.

Regards, Sergei

(*) I have a vague recollection that this could've been changed (may be partially) in 5.7. All I can see now is 19 PFS variables depending on table_definition_cache &&

Hi Sergei, On Mon, Nov 23, 2015 at 10:44:39AM +0100, Sergei Golubchik wrote: 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 2. we want to avoid early initialization of these 4 server variables and instead reinitialize PFS when they're autosized Thanks, Sergey

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