And so, it happened. After todays refresh of my Pg, I got:
$ SELECT version(); version ------------------------------------------------------------------------------------------------------------------------ PostgreSQL 9.2devel ON x86_64-unknown-linux-gnu, compiled BY gcc-4.5.real (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2, 64-bit (1 ROW)
Yes. We're in 9.2 development now. Looks like we got another really cool release coming soon.
Thanks a lot to all developers.
First of all, as of today, I added new feature, called anonymization.
It is for all of the people who are afraid that their plans contain information that they don't want to (or can't) share on the internet.
It works like this:
Continue reading explain.depesz.com – new feature and some new stats
Couple of important points:
The fix is important – in some cases, making backups off slave on 9.0 will not work.
By not work I mean that backups would be still done, but Pg wouldn't start from it. If started as slave, it would work OK, but you wouldn't be able to promote it to standalone.
New version of OmniPITR fixes that, as long as you're using -cm switch (and possibly some others like -h, -P, -U or -d – details in docs.
Version information is actually not really simple to get, it requires:
perl -I/opt/omnipitr/lib -le 'use OmniPITR::Program; print $OmniPITR::Program::VERSION'
But it works. It will be changed to normal –version option in near future.
Also, as you can perhaps see, we migrated to github.
Some time ago I wrote about getting fast pagination. While fast, it had some problems which made it unusable for some. Specifically – you couldn't get page count, and easily jump to page number N.
I did some thinking on the subject, and I think I found a way to make it all work. Quite fast. And with not big overhead. Let me show you.
After loooong pause, adding next (well, second) post to the “series“. This time, I'd like to describe how logging works. And I don't mean binary logging (WAL), but the log for us, humans, to read.
Before I will go to the postgresql.conf options, let me first describe what happens when PostgreSQL wants to log something.
Every now and then I need a function that returns nothing.
As you perhaps know, even defining function as “RETURNS VOID" doesn't fully solve the problem:
Continue reading Tips n' Tricks – return nothing from PL/PgSQL function
Today, on Stack Overflow there was interesting question.
Generally, given table that looks like this:
room | people | price | hotel 1 | 1 | 200 | A 2 | 2 | 99 | A 3 | 3 | 95 | A 4 | 1 | 90 | B 5 | 6 | 300 | B
Find cheapest combination of rooms that would accomodate given number of guests.
Continue reading Find cheapest combination of rooms in hotels
Today, I released 2 new versions (new features in 0.5, and then quick bugfix in 0.51) of Pg::Explain Perl library.
This is the base of explain.depesz.com – the code that does heavy lifting of parsing plans, and providing them in uniform way (object).
On 6th of March, Simon Riggs committed patch:
Efficient transaction-controlled synchronous replication. If a standby is broadcasting reply messages and we have named one or more standbys in synchronous_standby_names then allow users who set synchronous_replication to wait for commit, which then provides strict data integrity guarantees. Design avoids sending and receiving transaction state information so minimises bookkeeping overheads. We synchronize with the highest priority standby that is connected and ready to synchronize. Other standbys can be defined to takeover in case of standby failure. This version has very strict behaviour; more relaxed options may be added at a later date. Simon Riggs and Fujii Masao, with reviews by Yeb Havinga, Jaime Casanova, Heikki Linnakangas and Robert Haas, plus the assistance of many other design reviewers.
On 25th of February, Tom Lane committed patch:
Support data-modifying commands (INSERT/UPDATE/DELETE) IN WITH. This patch implements data-modifying WITH queries according TO the semantics that the updates ALL happen WITH the same command counter VALUE, AND IN an unspecified ORDER. Therefore one WITH clause can't see the effects of another, nor can the outer query see the effects other than through the RETURNING values. And attempts to do conflicting updates will have unpredictable results. We'll need TO document ALL that. This commit just fixes the code; documentation updates are waiting ON author. Marko Tiikkaja AND Hitoshi Harada