There are also already a bunch of tailored messages in other context:

I looked into this briefly, but I can't find a simple way to show all the current user's database permissions.

That covered everything that looked low-hanging.

Vaguely adjacent:

Now that we are on RDS I can confirm that MySQL also has ONLY_FULL_GROUP_BY enabled by default.

That actually using MySQL official Docker image.

There are only 23 occurrences of the string "GROUP BY" in the codebase, and, from inspection, many obviously do not conflict with ONLY_FULL_GROUP_BY.

Anecdata: locally, using 2 subprocesses went twice as fast (~85s -> ~42s). 4 subprocesses chopped another ~20% of the time off (~42s > ~35s). It stopped getting faster at 4. However, the largest table took 24s, so even if this was completely parallelizable we wouldn't expect it to drop lower than that.

Getting rid of the indirect writes on handle reads would probably be nice eventually, but doesn't directly accomplish anything today.

I applied this change to 20180208.maniphest.02.populate.php:

This remains desirable, but probably won't happen without a stronger motivator since the patches are somewhat involved.

Nothing really actionable here.

• your business faces regulatory/compliance issues which are satisfied by encrypting the connection, even if it provides no direct security benefit.

I don't run my Phabricator instance on Ubuntu but instead on RHEL6 (and with PHP7, which I know isn't officially support)

(I'll follow up in T13102 if there's more to be done here, it's possible that some installs are missing this for reasons other than "Ubuntu + apt get install php5-mysql").

We generally stopped seeing this after moving to InnoDB FULLTEXT, which seems less prone to table crashes than MyISAM FULLTEXT was. See also T12819 for the fate of InnoDB FULLTEXT.

Whoops this is probably my bad :-/

Closing this for lack of feedback, feel free to resurrect it if you get back to it.

This could definitely be more clear, but I think this is currently expected -- you still need to have valid configuration even when providing additional administrative credentials.

Do this man

I've marked D16909 as fixing this, but it just removes mysql.implementation, and uses the rule "mysqli if available, mysql otherwise".

I've banged on this a reasonable amount locally without issues and the originating instance reports that this seems to have calmed things down in production with these patches, so it seems like this pretty much just worked.

You are in the wrong place -- it looks like you mean to be on Uber's internal install of Phabricator, but this is the public upstream install of Phabricator.

Should be fixed in HEAD of master. Thanks for the report!

Source code isn't (AFAIK) stored in Phabricator's databases; it only lives at /var/repo/ and whatever other URIs you're mirroring/observing in Diffusion. But again, if you're just looking for commit-level metadata, using Conduit will probably be easier.

The use case is take all of that info as ETL input, but I what to be sure that I am not retrieveing source code from the tables as a matter of performance in addition to I am not interested in it.
What do you think is the best way to do that?

If you really want to muck around in Phabricator's databases, you could probably get at the information you mentioned with something similar to

The reason why I want that data is not relevant. The question in brief is the following the source code versioned by the repositories hosted in Phabricator are held in the data base?

Sorry, maybe I didn't explain that very well. I already understand you want the data, I don't understand why you want that data. The upstream isn't going to get into database nitty gritty without a Phacility Consulting contract ($1500 / hr if you're interested), but perhaps if you let us understand what problem you're trying to solve, we can give you pointers as to the best approach (APIs?)

Hello chad,

Might be quicker to simply tell us what you are attempting to do.

From the homepage:

Yeah, I'm fine with putting a global lock on this. You shouldn't really ever be running it on multiple hosts simultaneously (in the best case, this just slows you down by running the slow checks in adjust multiple times), but it's dangerous enough to explicitly prevent.

Happy to submit a patch if @epriestley is on board.

Oh, I take the hosts offline first.