This feed contains pages in the "debian" category.

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.

Posted Tue Feb 25 09:32:01 2014 Tags: debian

More and more packages are getting autopkgtest aka DEP-8 testsuites these days. Thanks to Antonio Terceiro, there is ci.debian.net" running the tests.

Last weekend, I've added a "CI" column on DDPO that shows the current test results for your packages. Enjoy, and add tests to your packages!

Posted Wed Feb 12 17:12:49 2014 Tags: debian

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.

Some googling suggested that the loose cable theory was indeed worth a try, so I took it apart. Thanks to a forum post I could then locate the display connector and fix it.

Putting the case back together was actually harder than disassembling it because some plastic bits got stuck, but now everything is back to normal.

Posted Sun Dec 8 20:36:44 2013 Tags: debian

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.

Posted Sun Sep 15 16:12:50 2013 Tags: debian

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.)

Posted Wed Jul 31 10:04:01 2013 Tags: debian

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

Posted Mon Mar 25 15:36:31 2013 Tags: debian

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!

Posted Thu Feb 7 13:24:58 2013 Tags: debian

So we finally made it, and sent out an official announcement for 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
Posted Fri Dec 7 10:31:58 2012 Tags: debian

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.

Posted Fri Nov 30 08:52:40 2012 Tags: debian

We have this PostgreSQL server with plenty of RAM that is still using some of its swap over the day (up to 600MB). Then suddenly everything is swapped in again.

It turned out the reason is there are two clusters running, and the second one isn't used as heavily as the first one. Disk I/O activity of the first cluster slowly evicts pages from the second shared buffers cache to swap, and then the daily pg_dump run reads them back every evening.

I was not aware of an easy way to get numbers for "amount of SysV shared memory swapped to disk", but some googling led to shmctl(2):

#define _GNU_SOURCE 1
#include <sys/ipc.h>
#include <sys/shm.h>
#include <stdio.h>
#include <unistd.h>

int main ()
{
        struct shm_info info;
        int max;
        long PAGE_SIZE = sysconf(_SC_PAGESIZE);

        max = shmctl(0, SHM_INFO, (struct shmid_ds *) &info);
        printf ("max: %d\nshm_tot: %ld\nshm_rss: %ld\nshm_swp: %ld\n",
                        max,
                        info.shm_tot * PAGE_SIZE,
                        info.shm_rss * PAGE_SIZE,
                        info.shm_swp * PAGE_SIZE);

        return 0;
}

The output looks like this:

max: 13
shm_tot: 13232308224
shm_rss: 12626661376
shm_swp: 601616384

Update: Mark points out that ipcs -mu shows the same information. Thanks for the hint!

# ipcs -mu

------ Shared Memory Status --------
segments allocated 2
pages allocated 3230544
pages resident  3177975
pages swapped   51585
Swap performance: 0 attempts     0 successes
Posted Mon Nov 26 21:17:36 2012 Tags: debian