Tag: waiting

Waiting for 9.1 – Reduced lock levels for ALTER TABLE

On 28th of July, Simon Riggs committed patch which:

Log Message:
-----------
Reduce LOCK levels OF CREATE TRIGGER AND SOME ALTER TABLE, CREATE RULE actions.
Avoid hard-coding lockmode used FOR many altering DDL commands, allowing easier
future changes OF LOCK levels. Implementation OF initial analysis ON DDL
sub-commands, so that many LOCK levels are now at ShareUpdateExclusiveLock OR
ShareRowExclusiveLock, allowing certain DDL NOT TO block reads/writes.
FIRST OF NUMBER OF planned changes IN this area; additional docs required
WHEN FULL project complete.

Continue reading Waiting for 9.1 – Reduced lock levels for ALTER TABLE

Waiting for 9.1 – standard_conforming_strings = on

Generally I write about new features, but this change is relatively important.

Yesterday, on 20th of July, Robert Haas committed following change:

Log Message:
-----------
Change the default value of standard_conforming_strings to on.
 
This change should be publicized to driver maintainers at once and
release-noted as an incompatibility with previous releases.

Continue reading Waiting for 9.1 – standard_conforming_strings = on

Waiting for 9.0 – Final Post ?

As of now, I am happy user of 9.1devel version of PostgreSQL:

=$ psql -c 'select version()'
                                                       version                                                       
---------------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1devel ON x86_64-unknown-linux-gnu, compiled BY GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
(1 ROW)

So, I guess no new features will make it to 9.0 – after all, 9.0 is currently already beta3.

If you want to get list of what I wrote about for 8.5/9.0 – just check the tag page.

Waiting for 9.0 – pg_upgrade

On May, 12ve, Bruce Momjian committed new contrib module for 9.0 – pg_upgrage.

As I understand – this is what was available before as pg-migrator.

If you're not familiar with it – it's a tool that allows upgrade of $PGDATA from some version to some version. What's the use case? Let's assume you have this 200GB database working as 8.3, and you'd like to go to 8.4 (or 9.0). Normal way is pg_dump + pg_restore – which will take some time. With pg-migrate/pg_upgrade it should be faster, and easier. So, let's play with it.

Continue reading Waiting for 9.0 – pg_upgrade

Waiting for 9.0 – extended frames for window functions

On 12th of February Tom Lane committed patch by Hitoshi Harada:

Log Message:
-----------
Extend the set of frame options supported for window functions.
 
This patch allows the frame to start from CURRENT ROW (in either RANGE or
ROWS mode), and it also adds support for ROWS n PRECEDING and ROWS n FOLLOWING
start and end points.  (RANGE value PRECEDING/FOLLOWING isn't there yet ---
the grammar works, but that's all.)
 
Hitoshi Harada, reviewed by Pavel Stehule

Continue reading Waiting for 9.0 – extended frames for window functions

Waiting for 9.0 – string_agg

On 1st of Februyary, Takahiro Itagaki committed a patch by Pavel Stehule which adds string_agg aggregate:

Log Message:
-----------
Add string_agg aggregate functions. The one argument version concatenates
the input values into a string. The two argument version also does the same
thing, but inserts delimiters between elements.
 
Original patch by Pavel Stehule, reviewed by David E. Wheeler and me.

Continue reading Waiting for 9.0 – string_agg

Waiting for 9.0 – removal of 0000000001.history check

I tend to write about new features in new versions of PostgreSQL, but this patch actually fixes one of the things that annoy me a lot, so here it goes:

On 26th of January, Simon Riggs committed:

Log Message:
-----------
Fix longstanding gripe that we check for 0000000001.history at start of
archive recovery, even when we know it is never present.

If you've ever tried to roll your own restore_command script ( like pg_standby ) then you know that to the algorithm that's presented in docs You always had to add special case for file “0000000001.history" – which was never there, but somehow PostgreSQL always asked for it – despite the fact that it could never arrive.

Now, thanks to this small patch we will no longer need to add this “if" in any script. It's small, and it's not a new feature, but I am SO happy to see it.