[Note to LiveJournal readers: this post is a week or so old, but I think I’ve finally vanquished the cross-posting demons]
When MovableType 5 was announced, there was a bit of a brouhaha about its lack of PostgreSQL support. Though it was completely unclear from the language of the announcement, all that meant was that PostgreSQL would not be officially supported and tested. The files would still ship with the distribution.
When MovableType 5 was announced, there was a bit of a brouhaha about its lack of PostgreSQL support. Though it was completely unclear from the language of the announcement, all that meant was that PostgreSQL would not be officially supported and tested. The files would still ship with the distribution.
I discovered this fact just after the Slackers’ Network machine explosion, as we rebuilt from the ground up. Still, in the interest of the expedience of the restoration, we opted to install the latest version of MovableType 4, since our RDBMS of choice is still “supported.”
But when it finally came time to turn my attention to MovableType, I discovered it worked haltingly, throwing cryptic error after error (Can’t use string (“x42494e3a53455247000000000000000”) as an ARRAY ref while “strict refs” in use), with little else to go on. Well, that string is clearly not an array ref, but where is it coming from?
So, I rolled up my sleeves and dusted off the debugging tricks I’d learned when building my custom MovableType plugins (before there was much in the way of documentation for MT4)
…And I got nowhere fast. I figured out quickly that the string in question was ASCII (possibly UTF-8) encoded as a hexadecimal string. But the deeper I went, the more sure I became that this was some kind of decoding bug, because the data seemed to go into the database just fine, but it was being garbled on the way out.
A few weeks ago I sat down with Matt and we tried to puzzle it out. I'd done a lot of work to characterize the bug, but was stumped. With a fresh pair of eyes, rather than getting wrapped up in debugging MovableType’s own serialization logic, he had the epiphany to go look at PostgreSQL’s own encoding formats.
Lo, and behold! There is a new, improved output encoding format in PostgreSQL 9.0. So much improved it has been made the default. What's more, it looks suspiciously like the strings I've been looking at in the debugger.
Armed with that information, it didn't take us long to track down the means to revert a client connection to the old format, and apply it to our MovableType instance.
In our case, adding
Setenv PGOPTIONS "-c bytea_output=escape" to the right portion of our Apache configuration was all it took.TL;DR : PostgreSQL 9 changed bytea encoding defaults, if you’re having trouble with MovableType, try setting connection options for your client.
