Category: PostgreSQL

The Elephant Versus the Bug

Debugging with PostgreSQL -- the Elephant takes on the Bug

Depending on the project, debugging can take 50 to 90% of development time. But it usually gets less than 10% of the press. PostgreSQL has great tools for debugging, but they are most effective when deployed as part of an overall strategy.

Ten days from now I’m doing a webinar on how best to do this. That’s 1pm, July 29th, 2020. You can register here.

It’s a fun talk: I focus on the key ideas, give a few good examples, have a quick quiz “There are three bugs on this slide: you have the next two slides to find them!” and then finish with some of my favorite debugging references: selected as particularly readable & practical.

[Update: the talk was given as planned. Thanks to Lindsay Hooper for great support! Video is online. And the audience of invisible Zoomers upped the number of bugs on the quiz slide from three to five!]

Last time I did this talk, my favorite piece of feedback was from Bruce Momjian, a founder of PostgreSQL and a member of the core team: Bruce said there was stuff he knew but hadn’t heard put into words, and stuff he just hadn’t seen yet.

And that’s how I hope this will be for you!

We will look at strategies for debugging PostgreSQL: how to find bugs, how to fix them, and how to keep them from happening in the first place.

We’ll look at root causes, technical tricks, and scientific strategies, and why — even if you can’t always write perfect code — it is usually a good idea to try.

We’ll hear from Bjarne Stroustrup, Sherlock Holmes, Kernighan and Ritchie, Pogo, & the experts of the PostgreSQL community.

Goal: less time debugging, more time building great tools and apps that stay up & get the job done.

If you can’t wait or just can’t make it, I have the latest version here: PDF, KeyNote, and PowerPoint, name your poison.

Update

Talk went off smoothly, about 65 or 70 attendees. The invisible Zoomers found two more bugs on the “quiz” slide! The event organizer, Lindsay Hooper of the PostgreSQL conference, did a great job setting every thing up, watching over a dry run, and giving feedback during. And she recorded and edited the webinar, so if you are interested in see the video “live”, herewith.

Now with more bugs: Debugging with PostgreSQL at FOSSCon 2019 – 8/17/2019

I am giving my Debugging With PostgreSQL talk tomorrow at FossCon. FOSSCon is the annual Free & Open Source Software Convention held every year in Philadelphia.

This version is lightly revised from last month’s version; added back in a few slides that I had to skip last time (I had 40 minutes last month, but 50 minutes tomorrow). And I fed back into the talk a bit of the audience feedback: more of what worked, less of the other stuff.

FOSSCon is fun, with a lot of great talks scheduled on Open Source & related. And it is free (donations are requested but not required.) Be seeing you.

Debugging with PostgreSQL – A Strategic (& Streamlined) Approach

Most popular slide at the talk: and the audience got all of them! (not counting the bit about the official name of Bangkok)

As planned, I gave a talk on Debugging with PostgreSQL at the Philly PostgreSQL conference at Wharton this last Friday (7/19/2019).

Went well: debugging is a great subject & I definitely struck a nerve with the audience; after the talk people were saying they knew about some of the points — which gave them some confidence — and others were new — which gave them some tools. Good.

My most popular slide was a quiz: only 10 lines of code — and from the PostgreSQL man page on foreign keys — but still three bugs. For the record, they are:

  • All of the data types should be domains, not physical types, so the city type should be something like “city_t”, defined as varchar(80). And the temperature should be, say, “fahrenheit_t” (or “celsius_t”), so you know what the units are.
  • The use of key words, like “date”, for field names is not great technique. It is ambiguous at best; breaks stuff at worst.
  • And the width for the city is way too small. Consider the name of Bangkok in Thai, the language of Bangkok: Krungthepmahanakhon Amonrattanakosin Mahintharayutthaya Mahadilokphop Noppharatratchathaniburirom Udomratchaniwetmahasathan Amonphimanawatansathit Sakkathattiyawitsanukamprasit. 177 characters! If you make the city’s type a domain, then you can revise the domain to be, say, “text” — and automagically get the type fixed everywhere you have a city reference.

I was scheduled to go late morning but went first because the opening speaker was still at his hotel. As a result I had the pleasant experience of hearing several later speakers refer to points made in my talk. The most popular was the phrase “lie consistently“.

I had built a form to collect Social Security numbers when I was at Bellcore (now Telcordia). It blew up when one fellow put in a variety of SSNs. I asked him what was going on. He said “I don’t want Bellcore to have my SSN. They have no legal right to it!”. “Fine by me, but just do me a favor & lie consistently“. We both left happy.

I did a run thru of the talk Sunday with my OTC (Official Talk Consultant); she pointed out, with her usual correctness, that I had tried to fit an entire software engineering course into 50 minutes. As a result, the early mornings & late evenings Monday thru Wednesday were spent reorganizing & rewriting. A 2nd run thru Wednesday evening went much better. OTC approved.

But when I did a final final talk & schedule check Friday morning I found the time blocks were now down to 40 minutes. Snip, snip, cut, cut, squeeze, squeeze. I cut out everything that wasn’t on message, useful, & fun. Definitely improved the talk. That which does not destroy us makes us strong. Or at least succinct.

Final version of the talk (PDF): Debugging with PostgreSQL — A Strategic (& Streamlined!) Approach.

WordPress Themes