Having recently been doing some debugging work where many watchpoints, conditional breakpoints etc were necessary I'd like to shout out to a really useful tool: The standalone CDT debugger.
It's part of the Eclipse project, but before you run screaming - it doesn't require project setup or anything and it serves as a good GUI gdb wrapper. It's good for working with PostgreSQL because you don't need to set up a fake IDE project or any such time-wasting business. You just launch the debugger. You've still got your .gdbinit with postgresql debug helper macros and everything.
Over at pgsql-general, Bráulio Bhavamitra asks:
I wonder if there is any plans to move postgresql entirely to a columnar store (or at least make it an option), maybe for version 10?
This is a pretty interesting question. Completely replacing the current row-based store wouldn't be a good idea: it has served us extremely well and I'm pretty sure that replacing it entirely with a columnar store would be disastrous performance-wise for OLTP use cases.
That doesn't mean columnar stores are a bad idea in general — because they aren't. They just have a more limited use case than “the whole database”. For analytical queries on append-mostly data, a columnar store is a much more appropriate representation than the regular row-based store, but not all databases are analytical.
If you've been following PostgreSQL development for the last few years, you've probably heard the term commitfest manager a few times. You probably already know what a commitfest is, but why is there a manager? Since I spent a good deal of time this past January managing one, I'll explain.
At its heart, a PostgreSQL commitfest is just a collection of patches awaiting integration into the PostgreSQL code base. A commitfest's working principle is that each patch that has been sent to pgsql-hackers must be reviewed timely; once reviewed and revised enough times, the patch is candidate for permanent inclusion into PostgreSQL by a committer.
As for the commitfest workflow: each new patch starts life in the commitfest in “needs review” state; it can be closed as “rejected” ( (more…)
I've always worked on PgJDBC, the JDBC Type 4 driver for PostgreSQL, with just a terminal, ant and vim. I recently had occasion to do some PgJDBC debugging work on Windows specifics so I set up Eclipse to avoid having to work on the Windows command prompt.
As the process isn't completely obvious, here's how to set up Eclipse Luna to work with the PgJDBC sources.
I've seen a number of users struggling with building PostgreSQL extensions under Visual Studio, so I thought I'd see what's involved in getting it working. The result is this tutorial, showing how to compile a simple extension with Visual Studio 2010 Express Edition.
You will need a supported version of Visual Studio installed. These instructions refer to Visual Studio 2010 Express Edition. It is not necessary to use the same Visual Studio version as PostgreSQL was compiled with, or the same version I'm using here. You do need to make sure your Visual Studio version is supported by the release of PostgreSQL you're targeting (or modify Configuration Properties -> General -> Platform Toolkit to use an older, supported toolkit). If you're not using VS 2010, some details (more…)
People are often hesitant to test out a new PostgreSQL release because they're concerned it'll break their current working installation.
This is a perfectly valid concern, but it's easily resolved with a few simple protective measures:
Build PostgreSQL from source as an unprivileged user
Install your PostgreSQL build within that user's home directory
Run PostgreSQL as that user, not postgres
Run on a non-default port by setting the PGPORT env var
If you take these steps the install its self cannot interfere at all. Starting and running the new PostgreSQL can only interfere by using too many resources (shared memory, file descriptors, RAM, CPU, etc) and you can just stop the new version if it causes any issues. The shared memory improvements in 9.3 make the shared memory (more…)
As my French colleague Dimitri Fontaine was pointing out a few days ago, PostgreSQL 9.2 is out. This is another great release for PostgreSQL, but we are already ahead in the development of the next release: PostgreSQL 9.3.
The Italian team of 2ndQuadrant has been working since last year on adding a new feature to PostgreSQL: support of referential integrity between the elements of an array in a table (referencing) and the records of another table (referenced).
We renamed it "Array ELEMENT foreign keys" - thanks to the feedback received from the hackers list. As you may have guessed, it is not part of the SQL standard. We have submitted a patch for 9.3, but currently it is still missing a reviewer.