Thom's memory leak

If you have been using PostgreSQL for a long time, or you’re relatively new but have been following old instructions about how to use it, it’s possible that you’re using features that have been deprecated. The reason features disappear tend to be because they have been superseded by better features which cover the same functionality. It’s important to try to avoid using features which are destined to disappear if there’s a newer alternative. Also when planning an upgrade, it’s useful to know if a feature you’re using will suddenly break in the new version. Some of these features still continue to work, but have since been removed from documentation because they’re to be removed in a future release. Others have just been removed completely. We’ll start off with the absurdly old and work our way to the present: Version 6.2 timetravel contrib module Does it still work?: No. This is ooooold and was last supported back in PostgreSQL 6.1. What’s wrong with it?: This really dragged p...

I've been changing a lot of my passwords lately so that none are alike. In fact they're so ridiculously random and lengthy that I wouldn't stand a chance remembering them. I've a means of obtaining these passwords though in a method known to me using encryption which requires 2 very different types of key, so remembering them isn't necessary. However, after going around trying to change my passwords, I've noticed that many places impose restrictions upon how long a password may be, and what characters you're allowed to use. For example, with PayPal, they absolutely require you to have at least 8 characters, but for some reason, it must not be any more than 20 characters. Why limit it at 20? Surely they hash the password anyway?... don't they? eBay have an identical restriction. And then came my bank (a Dutch bank which shall remain nameless). They also said that it must be at least 8 characters, but no more than 12. It must also contain at least o...

Look what arrived today (apologies for the poor quality pictures you're about to see). Yes, something wrapped in a coffee burlap bag. Which contains a rectangular hexahedron wrapped in rice paper sealed with stickers. It's a book! A quality-looking hardback book emblazoned with a shiny faceless figure donning a cape and glasses, and there's a strip of bright orange extending from the spine of the book. There's also a 4GB SDHC memory card stuck to the front. As you can see it's the special edition of With a Little Help by Cory Doctorow. This book is number 76 of 250. Let's have a look inside... We appear to have a letter addressed to "Bear" from Melissa Frain from Tor (no, not the Tor project, Tor the sci-fi folk). Bear? Anyway, it's a request for the review of a manuscript. And at the back we have... A sketch of what appears to be either a woman with a birthday cake stuck to her head, or a fairytale princess or some such variety of character...

There have previously been various posts on Writable Common Table Expressions (wCTEs) which demonstrate either performance gains or simple examples of how they work, but recently when giving some training, I wanted to come up with some new material to show folk that demonstrates an example of when you might wish to use it. Note that writable common table expressions are only possible in PostgreSQL, and only from version 9.1 onwards. But because 9.1 has been out for almost 2 months now, that means you can go and use this feature straight away! So in case you don't know what a writable common table expression is, in summary it's the same as a normal common table expression, except that you can also use UPDATEs, DELETEs and INSERTs with it. If you don't know what a normal common table expression is, it effectively let's you make the results of queries available to other queries in the same statement. What follows is a rather basic case, but the data is kept simple so as...

The first round of PostgreSQL Conference Europe talks have now been selected and already it's shaping up to be a great conference if these are any to go by. You can see the list so far at http://www.postgresql.eu/events/sessions/pgconfeu2011/ . If we take a brief look at a few of the talks, you'll see that you really don't want to miss this year's line-up. Firstly we have a talk by PostgreSQL veteran and core team member Bruce Momjian who will be "Explaining the Postgres Query Optimizer". This will enlighten attendees as to how PostgreSQL makes its decisions in response to queries which is important to understand in order to know how best to ask PostgreSQL what you want. Bruce gave a very popular MVCC talk last year, and no doubt this one will be one to watch. Also, Michael Meskes's talk entitled "Mission impossible? Can I replace my most important databases with PostgreSQL?" won't be a brief "yes", but will elaborate on Mi...

Peter Geoghegan (@sternocera) has just joined us on Planet PostgreSQL but unfortunately his post (which looks like he's put quite a bit of work into it) became too old to list on the main site's front page before his account was approved, so here's me waving my arms to give you a second chance to find it. You can read it here .

So I went to the No2AV website, and clicked on the link entitled "Why vote no" to see what reasons they've cooked up. Let's take a look: AV is costly They argue, as they keep arguing, that AV will cost up to an additional £250 million: "Local councils would have to waste money on costly electronic vote counting machines and expensive voter education campaigns." What about the extra £800 million they'll also have to spend on red carpets, gold-trimmed ballot papers and free meringue and strawberries served to voters as the booths? What about those? Yes, of course, there's no such cost, because they won't be used. No-one said they would need to be used. They harp on about how Australia is the only other country to use AV to vote in the lower house, but they conveniently ignore the fact that Australia doesn't even use electronic voting machines. "With ordinary families facing tough times can we really afford to spend a quarter of a bill...