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]

The '@' suppresses the error successfully.
I could not see any problems when importing and browsing a repository but didn't test anything else.

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.

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:

Error while executing task ID 10241 from queue. {>} (AphrontCharacterSetQueryException) Attempting to construct a query containing characters outside of the Unicode Basic Multilingual Plane. MySQL will silently truncate this data if it is inserted into a utf8 column. Use the %B conversion to escape binary strings data. at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:346]

Maybe there's a way to fail more gracefully in this condition. Either allow truncation or replace these on old mysql versions.
Otherwise i could break any phabricator installation running on an older mysql by commiting such a character.

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).

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

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.

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 ;)

Sure:

• 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.