December 20th, 2000

ugh

before I pass out and die, let's see if I can remember all the shit I did tonight. it seems that everything I tried to do one thing I got off on a tangent and just had to do something else.

* I thought, oh, tonight I'll fix the clock on livejournal. (it's been an hour ahead... so I was going to need to stop the database to take it down)

* I wrote the list of SQL statements to fix all the times that were 55:24 ahead.

* I realized fixing the talkpost table was stupid, since it was going away so soon. I then thought, oh, I'll just finish the transition to the new talk tables tonight! (oh god.. this is where it gets messy)

* So, I prepared to take down the site and run my talkpost -> talk/talktext/talkprop migration queries.

* ran the first query ... boom. mysql hates it. turns out one of the indexes on the talkpost table (1M+ rows now) was corrupted. had to take down everything and repair it.

* ran the query again ... stall. the new table file on disk isn't growing. had to take the webserver down so mysql would have enough CPU to ever get around to it.

* even after testing the new talk code for the last few days, I found bugs.

* none of the anonymous comments got posted. now that we store IDs all over the place, I started using 0 to refer to anonymous.. to make a long story short: i changed a few joins into left joins and things were cool.

* splitting the tables made the delete journal entry logic more complicated. you now have to SELECT talkid FROM talk WHERE nodetype='L' and nodeid=$itemid and then delete all those talkids from all three tables.

* so ... I made LJ::delete_item($dbh, $ownerid, $itemid) in ljlib.pl. now the protocol handler calls this instead of doing it all manually (since it's no longer simple... it used to be about 3 queries... now it's 11.)

* now LJ::delete_user can be finished... since it needed a delete_item call. now I can finally finish the purge users script.

* noticed deleting a friend group was slow because you had to go through all your old posts and turn off the bit in the allowmask. even with the tight log table now, this is slow... logs of disk blocks have to be read it.

* so, created a table logsec that keeps track of (ownerid, itemid, allowmask) ... it gets a row whenever there's an item with security of "usemask" (which is Friends Only and Custom).

* had to import data into this, then modify the protocol handler to keep it updated.

* I haven't yet modified the protocol handler to *use* this new information to solve the original problem.

okay

alright, I think things are happy:

* talk stuff is all done
* deleting friends groups is fast

things that are not happy include:

* the system clock (to be fixed tomorrow night)
* my goddamn cough that won't go away

image prefix

in the process of converting a bunch of images over to thttpd that were still being served from apache (all the talk subject icons, etc..), i found I found that there were some BML pages that were static (no perl) so they didn't include ljlib.pl, which means ljconfig.pl was never pulled, and $LJ::IMGPREFIX wasn't defined, so I had the www.livejournal.com:8080/ hard-coded in there.... instead, I moved it to cgi-bin/bml/global.look, defined as IMGPREFIX=> ... so now in bml pages I can just do img src=(=IMGPREFIX=)/goat.gif ... or whatever.

at least it's only redudant in two places now.

hmmm

livejournal sends out way too much mail. postfix stopped sending mail for awihle and 2,000 messages queued up. i kicked postfix' ass and now it's sending again.

root@www:/var/spool/postfix/incoming# ls -l | wc -l
2187
root@www:/var/spool/postfix/incoming# ls -1 | wc -l
2162
root@www:/var/spool/postfix/incoming# ls -1 | wc -l
2157
root@www:/var/spool/postfix/incoming# ls -1 | wc -l
2137
root@www:/var/spool/postfix/incoming# ls -1 | wc -l
2127
root@www:/var/spool/postfix/incoming# ls -1 | wc -l
2126