Over the past few weeks, new distributions have been added on apt.postgresql.org: Ubuntu 13.10 codenamed "saucy" and the upcoming Ubuntu LTS release 14.04 codenamed "trusty".
Adding non-LTS releases for the benefit of developers using PostgreSQL on their notebooks and desktop machines has been a frequently requested item since we created the repository. I had some qualms about targeting a new Ubuntu release every 6 months, but with having automated more and more parts of the repository infrastructure, and the bootstrapping process now being painless, the distributions are now available for use. Technically, trusty started as empty, so it hasn't all packages yet, but of course all the PostgreSQL server packages are there, along with pgAdmin. Saucy started as a copy of precise (12.04) so it has all packages. Not all packages have been rebuilt for saucy, but the precise packages included (you can tell by the version number ending in .pgdg12.4+12 or .pgdg13.10+1) will work, unless apt complains about dependency problems. I have rebuilt the packages needing it I was aware about (most notably the postgresql-plperl packages) - if you spot problems, please let us know on the mailing list.
Needless to say, last week's PostgreSQL server updates are already included in the repository.
My ASUS Transformer TF101 had suddenly started flickering in all sorts of funny colors some weeks ago. As tapping it gently on the table in the right angle made the problem go away temporarily, it was clear the problem was about a loose cable, or some other hardware connection issue.
As I needed to go on a business trip the other day, I didn't look up the warranty expiration day until later that week. Then, Murphy struck: the tablet was now 2 years + 1 day old! Calling ASUS, some friendly guy there suggested I still tried to get ASUS to accept it for warranty, because the tablet had been with them last year for 5 days, so if they added that, it would still be within the warranty period. I filled out the RMA form, but one hour later the reply was they rejected it because it was out of warranty. Another guy on the phone then said they would probably only do the adding if it had been with them for maybe 10 days, or actually really 30 days, or whatever.
Putting the case back together was actually harder than disassembling it because some plastic bits got stuck, but now everything is back to normal.
If you are upgrading your HP/Compaq 6715b to Debian Jessie, and suddenly Wifi stops working because the PCI device is gone, install the "rfkill" package:
# lspci | tail -2 02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02) 10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) # rfkill list 1 1: hp-wifi: Wireless LAN Soft blocked: yes Hard blocked: no # rfkill unblock wifi # rfkill list 1 1: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: no # lspci | tail -2 10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) 30:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 02)
Reports on the internet say that the same could be done by going into the BIOS and selecting "Reset to default" - this makes the Wifi LED active until about udev is started on the next boot.
To be done: figure out how to automate this.
Following an idea by Ansgar Burchardt, I've done some digging on version numbers in Debian:
Most common version numbers:
projectb=> select version::text, count(*) from source group by 1 order by 2 desc; version | count ------------+------- 4:4.10.5-1 | 131 1.0-1 | 120 1.0.0-1 | 95 1.1-1 | 95 1.0.1-1 | 93 1.2-1 | 88 1.0-2 | 82 0.2-1 | 80 0.3-1 | 79 0.5-1 | 77 0.04-1 | 76 1.1.1-1 | 76 0.10-1 | 74 1.4-1 | 72 1.1-2 | 71 0.1-1 | 70 0.11-1 | 70
Version number with the most spellings: (considered equal by the dpkg definition, implemented in the "debversion" type)
projectb=> select version::text, count(*) from source where version = '1.02-1' group by 1 order by 2 desc; version | count ------------+------- 1.2-1 | 88 1.02-1 | 46 1.002-1 | 4 1.000002-1 | 1 001.002-1 | 1 1.00002-1 | 1
If we look at equivalent version numbers, the first table above looks entirely different:
projectb=> select version, count(*) from source group by 1 order by 2 desc limit 30; version | count ------------+------- 0.3-1 | 162 1.0-1 | 160 0.05-1 | 156 0.04-1 | 154 0.02-1 | 151 1.02-1 | 141 0.006-1 | 133 1.001-1 | 131 4:4.10.5-1 | 131 0.7-1 | 127
(I'm also participating in the "longest version number" contest, I've just uploaded bind9 version 1:9.8.4.dfsg.P1-6+nmu2+deb7u1~bpo60+1 to backports.)
We were lazy and wrote a simple PostgreSQL monitoring check in shell instead of using some proper language. The code looked about this:
out=$(psql -tAc "SELECT some_stuff, t > now() - '1 day'::interval FROM some_table" some_db 2>&1) case $out in *t) echo "OK: $out" ;; *) echo "NOT OK: $out" ;; esac
If the string ends with 't', all is well, if it ends with 'f' or someting else, something is wrong.
Unfortunately, this didn't go that well:
OK: psql: FATAL: database "some_db" does not exist
We've just put the new PostgreSQL minor releases live on apt.postgresql.org. Building 5 major versions for 10 distributions produces quite a lot of stuff:
- 25 .dsc files (source packages)
- 745 .deb files (360 *_amd64.deb + 360 *_i386.deb + 25 *_all.deb)
- 497 MB in *_amd64.deb files
- 488 MB in *_i386.deb files
- 58 MB in *_all.deb files
- 73 MB in *.orig.tar.bz2 files
- in total 1118 MB
Compiling took a bit more than 10 hours on a 2-cpu VM. Of course that includes running regression tests and the postgresql-common testsuite.
Note: This will be the last update published on pgapt.debian.net. Please update your sources.list entries to point to apt.postgresql.org!
This new repository hosts packages for all PostgreSQL server versions (at the moment 8.3, 8.4, 9.0, 9.1, 9.2) for several Debian/Ubuntu distributions (squeeze, wheezy, sid, precise) on two architectures (amd64, i386). Now add packages for extension modules on top of all these, and you get a really large amount of binaries from a small number of sources. Right now there's 1670 .deb files and 148 .dsc files, but the .dsc count includes variants that only differ in the version number per distribution (we attach .pgdg60+1 for squeeze packages, .pgdg70+1 for wheezy and so on), so the real number of different sources is rather something like 81, with 38 distinct source package names.
Dimitri Fontaine, Magnus Hagander, and I have been working on this since I first presented the idea at PGconf.EU 2011 in Amsterdam. We now have a Jenkins server building all the packages, an archive server with the master repository, and a feed that syncs the repository to the postgresql.org FTP (well, mostly http) server.
If you were previously using pgapt.debian.net, that's the same archive as on apt.postgresql.org (one rsync away). Please update your sources.list to point to apt.postgresql.org, I'll shut down the archive at that location at the end of January.
Here's the Quickstart instructions from the Wiki page:
Import the repository key from http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc:
wget -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
Edit /etc/apt/sources.list.d/pgdg.list. The distributions are called codename-pgdg. In the example, replace squeeze with the actual distribution you are using:
deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main
Configure apt's package pinning to prefer the PGDG packages over the Debian ones in /etc/apt/preferences.d/pgdg.pref:
Package: * Pin: release o=apt.postgresql.org Pin-Priority: 500
Note: this will replace all your Debian/Ubuntu packages with available packages from the PGDG repository. If you do not want this, skip this step.
Update the package lists, and install the pgdg-keyring package to automatically get repository key updates:
apt-get update apt-get install pgdg-keyring
We have a PostgreSQL server with 16 cores that was apparently running well below its capacity: load something between 3.0 and 4.0, around 200 active database connections, almost all always being <IDLE>. However, when the tps count reached 7k transactions per second, things started to throttle, and pgbouncer (running on the database server) started listing up to half of the client connections to be in cl_waiting state. Load was still low, but application performance was bad.
The culprit turned out to be the kernel scheduler, fairly distributing CPU time among all running processes. There's one single pgbouncer process, but hundreds of postgres processes.
A simple renice of the pgbouncer process did the trick and gave us another extra 2k tps.
This blog is powered by ikiwiki.