Resolved by D18959 + D18960. See also T13049.

Even on our fairly normal data, the effect was a little bit more dramatic than I'd expected:

D18962 uses this to implement "Export Data" for large result sets.

I'm going to optimize + probe secure001 now and see if any of the tables above shrunk. I'm expecting a very modest effect combined with zero user visible changes in the UI despite throwing away a bunch of data.

Took like 3-ish minutes and did this:

I double checked that our backups are working.

Editing some edges on the new code as a sanity check before I compact things.

(Pushing this to secure, stuff might be funky for a minute while I gently massage the database.)

It looks like PHPExcel was formally deprecated on December 24, 2017 but I'm not planning to switch to its successor, PhpSpreadsheet, until we run into some specific motivator.

See PHI324.

See PHI323.

This hasn't had any stability issues for a while.

transaction.search now returns comments and inlines, including path, line, length, and reply information.

I think everything we know about has been resolved.

This is resolved as far as I'm aware. See also T11767 (improvements to these limits), PHI125 (similar issue with non-UTF8 attachments failing to insert) and T13053 (planning).

I'm rolling this forward into T13053.

If that doesn't work, you might try adding some logging to PhabricatorDaemonEventListener->handleLogEvent() to see if the sequence of events you're receiving matches my expectations or not. It's hard to log out of this context because normal tools (var_dump(), phlog(), throw new Exception(), etc) won't necessarily end up anywhere very helpful, but you can do this to create an ad-hoc logfile:

The daemon log (at /daemon/) shows status icons for running (or recently-known) daemons. This stuff lives in PhabricatorDaemonLogViewController. The status PhabricatorDaemonLog::STATUS_WAIT represents two (slightly-more-than-two) different scenarios:

My plan is to pick those to stable, then compact-edges here on secure, then compact-edges on the affected 130GB instance. There's some value in doing this sooner rather than later because the backups for 130GB of edge data are having some issues. The instance is a free test instance so this isn't a huge concern, but I'd sleep better if it was running smoothly. If you don't run compact-edges I think the worst those changes could really do is cause some kind of temporary display bug with new transactions, so the risk should be pretty small.

Bad news: data still has one reader/writer in the Asana-to-Revision linking implementation. So we can't completely get rid of that yet.

this can probably be figured out by examining the 2.16.0 release notes

T4675 survives this, because rendering policy controls on the client is very complicated.

T13049 is a followup about generalizing exporters.

This is quite old and I have no idea how to reproduce it and thus no idea how to fix it. Locally, I tried a few things and wasn't able to identify a case where the Herald field value differed from my actual project list.

I'm rolling this forward into T13049. See also D18919.