this build fix
, verifying that it works on Cygwin, and that it doesn't break the Linux/BSD builds or the MinGW Windows builds. Your help would be appreciated in ensuring that Cygwin remains a supported platform into the future.
If you use PostgreSQL on Cygwin, please try out
SELinux / SEPostgreSQL users: There are some proposed improvements in the 2013-01 commitfest that might go into PostgreSQL 9.3 - but only if you help.
Interested users are needed to try out the following patches and report back with their experiences if you want to see these changes in 9.3:
The patches are:
Add a new event type of object_access_hook named OAT_POST_ALTER. This allows extensions to catch controls just after system catalogs are updated. Patch also adds sepgsql permission check capability on some ALTER commands, but not all.
This patch adds sepgsql support for permission checks equivalent
to the existing SCHEMA USE privilege:
QueryNameInformationFile is the IRP_MJ_QUERY_INFORMATION operation of ZwQueryInformationFile
as documented in MSDN here
. It's a kernel-level operation.
I'm yet to determine the root cause of the issue. To work around the problem, build in a shallower directory tree.
I've included a bunch of details after the cut, primarily to help anyone else with this problem find this post.
I just confirmed the cause an extremely weird problem that's been frustrating me for days. I want to share it so nobody else has to waste their time on this.
It appears that - at least on my build machine, a Windows 7 SP1 x64 box with Windows SDK 7.1, Visual Studio 2010 Express SP1 and Visual Studio Express 2012 on it - vcregress check will hang indefinitely with a postgres.exe process sitting at 100% cpu if the regression tests are run in a path that is too deep. This seems to happen with both x64 and x86 builds.
git.exe seems to have a similar problem, where a git clean -fdx in a deep directory tree will sit at 100% cpu forever, making no progress.
In both git.exe's and postgres.exe's cases, Process Monitor shows a steam of QueryNameInformationFile events with result BUFFER OVERFLOW.
That's right. Melbourne will be hosting the first Australian PostgreSQL Day, on February 4.
The momentum continues as PGDay national events now expand to include the Asia Pacific region. Australia joins the long list of countries which have embraced the Community spirit that is the fundamental principle of the PostgreSQL project: Brasil, China, Argentina, Ecuador, Canada, Italy, France, Germany, UK, USA, Japan, Holland, Czech Republic, ...
I chose an AC/DC song title because not only they are an Australian band, one of the greatest of all times in fact, but they also named a lane way in Melbourne after them.
The event has been organised thanks to Jason Godden from the Melbourne PostgreSQL Users Group and will be hosted by Experian Hitwise in St Kilda Road. It will be a special
As part of some internal continuous integration and testing work, I've put together some scripts to simplify the compilation of PostgreSQL on Windows.
PostgreSQL its self is pretty easy to compile on Windows. You download and install ActiveState Perl and Visual Studio or the Microsoft Windows SDK, unpack a PostgreSQL source tree, copy config_default.pl to src\tools\msvc\config.pl, edit it to reflect your environment, open an SDK command prompt for your Windows SDK version / Visual Studio version, cd to the PostgreSQL directory, and run src\tools\msvc\build.pl. Not too bad.
The trouble is getting the dependencies built, and that's what I'm working on improving. The scripts I've published at http://github.com/2ndQuadrant/pg_build_win are a step toward that. I've written some NMake
Version 1.1.2 of Barman, backup and recovery manager for PostgreSQL, has been officially released and is publicly available for download.
This minor release includes:
Support for the "configuration_files_directory" option that allows to include multiple server configuration files from a directory
Support for special backup IDs: latest, last, oldest, first
Management of multiple servers to the 'list-backup' command: 'barman list-backup all' now list backups for all the configured servers.
Support for "application_name" management for PostgreSQL >= 9.0
Fix of bug #18: ignore missing WAL files if not found during delete
Download and general information
You can find more information on Barman at www.pgbarman.org.
RPMs for RHEL/CentOS 5 (dependencies
is the possibility to remotely backup multiple PostgreSQL servers from one single backup host. The upcoming version 1.1.2 of Barman will make this much easier from a system administrator's point of view. Let's see why.
One of the key aspects of
The sixth edition of the Italian PGDay took place in Prato at the Monash University Centre last Friday, November 23rd.
As president of the Italian PostgreSQL Users Group (most likely for the last time) and host of Prato, I had the pleasure to open the event and welcome all the attendees - coming from 11 regions of Italy. 79 real attendees (PostgreSQL users and potential ones), plus 16 among speakers and staf, for a total of 95 participants. It is a remarkable result for such a specific open source advocacy event!
95% of the attendees were from the central and northern parts of the peninsula, 4% of them from the southern part.
Organising a PGDay is always a tiring activity. However, it can be very rewarding too. Especially if you see that every year, more and more people are
and this one
. It turns out that some - probably rare - Windows installs have an incorrect %COMSPEC% environment variable. This causes popen to fail with the wonderfully useful error message: "No error" when initdb tries to execute the PostgreSQL backend. The message displayed to the user is:
Problem running post-install step. Installation may not complete correctly. The database cluster initialisation failed.
... which can be caused by several different issues
, of which this is only one.
Today I ran into another strange issue with PostgreSQL installation on Windows. It turned out not to be a problem with the installer; instead it was a form of broken Windows installation that I hadn't seen before, so I thought I'd write it up.
The installer already contains checks for several kinds of broken Windows install. For example, it tests to make sure that %TEMP% is writeable, and to makes sure the vbscript interpreter actually works. These were both the cause of frequent problem reports to the mailing lists in the past.
This is a less common issue, though it's clearly turned up in the wild before, as shown by
Questions periodically come up on the PostgreSQL mailing list regarding Amazon EC2 and how to get PostgreSQL to perform well on it. The general feeling on the list appears to have been that EC2 performs very poorly for database workloads, at least with PostgreSQL, and it doesn't seem to be taken particularly seriously as a platform. I certainly thought of it as a last resort myself, for when other constraints prevent you from using a proper VPS or real hardware.
I had the chance to meet with a high level AWS support engineer last week. It's prompted me to write up the basics of configuring EC2 instances for decent PostgreSQL performance. I haven't had the chance to back the following advice with hard numbers and benchmarks yet, so remember: Always test everything with a simulation of