@kylejao, I don't know why mysql would hang indefinitely on an ALTER TABLE statement. I can't reproduce that, and it seems like an issue with MySQL, not Phabricator. I don't know if there are more granular tools available to help understand why ALTER TABLE isn't working or not. You could try googling or looking on StackOverflow. It looks like Percona might have some tools, although I haven't used them.

(It's technically deterministic, I suppose, just very unpredictable.)

Here's an example which shows how zany things are:

Some vague thinking in this vein:

so is there anything I can do with this?

Still stuck..

The machine shouldn't be slow. Let me wait longer. Thanks.

Looks like that table has 6.5GB of data in it, so it could take MySQL quite a while to ALTER it. I would not normally expect it to take 2 hours, but if you have a slow machine or disk maybe it's just legitimately taking that long.

The part of phabricator_repository:

phabricator_repository            6,551.8 MB   97.5%
    repository_branch                 0.0 MB    0.0%
    repository_badcommit              0.0 MB    0.0%
    edgedata                          0.0 MB    0.0%
    repository_summary                0.0 MB    0.0%
    repository_coverage               0.0 MB    0.0%
    repository_statusmessage          0.0 MB    0.0%
    repository_arcanistproject        0.0 MB    0.0%
    repository_symbol                 0.0 MB    0.0%
    repository_vcspassword            0.0 MB    0.0%
    repository_pushevent              0.0 MB    0.0%
    repository_mirror                 0.0 MB    0.0%
    repository_auditrequest           0.0 MB    0.0%
    repository_lintmessage            0.1 MB    0.0%
    repository                        0.1 MB    0.0%
    repository_pushlog                0.1 MB    0.0%
    repository_refcursor              0.3 MB    0.0%
    edge                              0.3 MB    0.0%
    repository_transaction            0.3 MB    0.0%
    repository_parents                0.4 MB    0.0%
    repository_commitdata             2.6 MB    0.0%
    repository_commit                 3.2 MB    0.0%
    repository_filesystem             5.0 MB    0.1%
    repository_pathchange           129.0 MB    1.9%
    repository_path               6,410.0 MB   95.4%

It depends on the size of the table.

like 2 hours.
I'm running this command from MySQL. How long is it expected to finish?

Equivalently, if you run this command manually from MySQL, does it complete quickly?

If you have a large amount of repository data, the migration may take a very long time. How long is it hanging for?

Hi, my adjustment hangs. Wiith --trace I got

Oh, I thought this was about the global search. The existing patch only covers the global search in the upper right.

I can reproduce it on the WMF install in tokenizers:

When I type "Wikidata" on your install its the top result:

Wikimedia upgraded yesterday, and while typing "Wikidata" seems to bring "Wikidata" among the top five suggestions, it is not the top result, which makes us think that we can still run into scenarios like the one described here.

Ugh. I guess we'd have to this thing, then:

There seems to be no other way than setting the timeout via ini_set().

Let us know if you're still seeing issues with large queues after those patches, but I think the meat of this issue is fixed.

We narrowed this down in IRC to the call to set_charset('utf8mb4') failing with this error:

Adjust has been run on our db and /config/database/ reports 'No Schema Issues'. However, if I try to create a ticket with a cute title like ? ? ? ? ? ? ? ? ? I get:

Closed by commit rP81a13ed8bda8.

I want to build this some day but it isn't going to happen for a while and doesn't block SAAS.

Support Impact This is broken with no real workaround.

Closed by commit rPHUb7c05df35726.

• Use Config → Database Status and Config → Database Issues from the web UI to sanity check things before applying the schema adjustments. It's expected that there will be a ton of warnings (around 3,000) but no errors.
  • • The majority of these should be things which are currently utf8_general_ci or utf8_bin that are "expected" to be binary.
    • If there are errors, let us know.
  • Run bin/storage adjust to apply the changes, optionally adding --trace if you want more insight / better logging into what's going on.
    • If this is unable to apply any changes, let us know. (I've done one schema conversion to binary but it was a few patches ago and it might have some issues now.)
  • Config should now show no warnings.
  • Set $has_utf8mb4 = true; near line 329 of libphutil/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php to actually disable the exception and fix the issue.

as mentioned this is a dev install just for me. i'd be happy to test with a mysql 5.1 if you like. doesen't matter if it completely breaks ;)

They're merged and available, but you have to run a dangerous secret script to actually apply them and do the conversions. We'll make that part of bin/storage upgrade once it stabilizes.

Ah i see. I thought the changes were already merged. My dev installation i've made earlier today still has utf8_general_ci.

T1191 converts the schemata to utf8mb4 where available, and binary where not available, and fixes the issue correctly (by permitting storage of 4-byte characters on all MySQL versions). It's running on this install (which is why emoji work here) but not ready for general use yet (we're still uncovering a handful of minor issues). You can find a great deal more discussion in that task. The issue isn't old versions of MySQL, it's our use of utf8 character sets (which are basically completely broken).

Upon importing the phabricator repo the import will stop at 99% because the last commit containing the unicode char can't be imported.
Error is the same that initially triggered the whole problem:

Thanks! I just wanted to make sure @ resolves it, since my versions of things don't reproduce it locally. I'll get a patch out.

I've just set up a new dev phabricator today using a mysql 5.1.41
Error logs are flooded with (for every query): ERROR 2: mysqli::set_charset(): Error executing query at [.....libphutil/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:70]