Chasing Nuts

Just a heads up to crew running WordPress. There is a new version to fix some bugs in the 1.5.1 release. You should head over to http://wordpress.org/download/ and get updated.

As you all likely know I am a big Slony fan. That said we do not always see eye to eye. This was the case this weekend! We rolled out an update and had a SQL file all ready to get passed to Slony and pushed to all the PostgreSQL instances in the cluster. The SQL file ran just fine on the Master but when it had to run on the slave things did not go so well.

INSERT INTO cdsp_apptype_map (xfertype, cdsptype) VALUES (”FDXF”, ”CDSPFORD”);

‘); insert into “_adxclust”.sl_confirm (con_origin, con_received, con_seqno, con_timestamp) values (1, 2, ‘150′, CURRENT_TIMESTAMP); commit transaction;” PGRES_FATAL_ERROR ERROR: could not find trigger 40749

That last part about not finding the trigger really did not make my day. For those who do not know when running slony you can not have any triggers fire on a table that is is in the slave set. You may wonder how they disable triggers. The trick is they change the OID so that they can not be found. That all seems like a fine and dandy idea till you have a SQL script that expects triggers to work! So lesson learned and now I need to go over the SQL files we role out to Slony much more closely. The good news is that the Slony folks are already aware of this problem and there is a patch to address it. I just hope this all gets fixed in the next version of Slony and that gets out before our next production database update.

So what is the real story behind Real ID??? I am not sure I know and I am not sure anyone really knows, but Real ID will not lead to good things down the road. For more information on Real ID take a look at this c|net article.

I really have to give c|net some merit for not beating around the bush with this article. I loved this part:

Q: Why did these ID requirements get attached to an “emergency” military spending bill?
Because it’s difficult for politicians to vote against money that will go to the troops in Iraq and tsunami relief.

Maybe I am wrong, maybe I should give the benefit of the doubt to the government but I am really worried about this. You see once the floodgates are open, they can’t generally be closed. I can see it now, hmm you want to cross a state line and to do it you need to swipe you Real ID. This so much remind me if the talk about papers in The Hunt for Red October. There is a scene when the captain is talking to his officer about traveling and he says no papers, yup no papers. So this may not be a paper but I think it is worse. If this thing ends up with RFID then they can just put a sensor at the state line. How long till this system gets hacked by some 12 year old and everyone in the world know where I do my banking and where I drive.

So you may wonder why do I care. I do not really, I am usually very open and if someone wants to know where I am going they ask and I am sure to tell. The point is that I feel this could lead to some real invasions of my privacy.

Did you know Texas is considering RFID tags on all license places, and yes, police would scan them automatically for criminals in the like, I’d say the “tracking system” infrastructure is already being put in place. (Only if the license gets an RFID tag, now they’ll know if someone’s borrowing your car or not.) And as more and more things are RFID-mandated, more and more government buildings will have readers, then like red-light cameras they’ll be red-light RFID readers (to help catch people who run red lights, of course)… The end result will indeed be tracking of everyone’s movements. Technology as an oppressor. NO ONE has to have that idea in mind now for that to be what happens; it’s simply where the current trend will end up.

Yesterday was not just the first day for my new web site. It was also the day I rolled out a major project at Autoweb. The project was, surprise surprise, deployment of our new postgres replication system using you guessed it Slony-I. sure we had done lots of testing so one might say why would you think there could be any problems. Unfortunately no matter how much testing we do, its nothing like between the hours of seven and eight and the morning when the server was going to get 3000 users slamming it. Good old postgres ran like a champ! I sat there watching all day expecting something to go wrong but know nothing of any excitement the server just kept running and running queries and the slave servers stayed fully replicated. So I think I’m in a go-ahead and give this project a cautious thumbs up will get another couple weeks to make sure nothing breaks but I think we got one right.

I guess that means tomorrow I can start on the next phase of the project true hot failover. Using something like heartbeat I need to detect when the primary postgres server goes down and rolling everything over to the secondary without the users ever knowing. Things get a lot crazier here and I certainly don’t want my script to accidentally roll over to the slave when the masters still is the master.

All this reminds me with my recent work on postgres and Slony-I replication I have some scripts are really need to try to get put into the CVS tree. One in particular is really slick at finding objects not being replicated thank you Brian for the help with that one.