sorted by: recent | see :
popular
Content Tagged with PostgreSQL + postgres
Reading between the lines of EnterpriseDB?s survey results
EnterpriseDB has announced the results (PDF) of its recent survey of open source database usage.
While the company understandably highlights the adoption of PostgreSQL for transaction-intensive applications and its high reliability and performance and scalability EnterpriseDB has done a pretty good job of presenting the results in an unbiased manner.
I couldn’t help feeling that some of the more interesting results are hidden at the end of or buried within EnterpriseDB’s write-up, or even missing entirely, however.
For example, right at the end of its report EnterpriseDB states that “eight three percent have yet to pay for the use of their open source database” which speaks volumes about both the challenge that open source database vendors face in converting users to paying customers and the opportunity that is open to them if they can find a solution.
The company also states that “a majority of respondents indicated that they used an open source database in order to migrate away from their use of Microsoft SQL Server and Oracle commercial databases” which is technically accurate but a little misleading. It further adds that “less than one percent indicated they moved off of IBM DB2 to an open source database. Microsoft SQL Server was the highest at eleven percent while Oracle was at six percent.”
EnterpriseDB doesn’t tell us how many migrated from ‘other databases’ (which was the other answer available) but I think it’s fair to say that the majority of respondents in fact indicated that they had not used an open source database in order to migrate away from a proprietary database.
This supports the results we saw in our own recent open source database report as well as recent results from a Forrester survey. As I told eWeek in response to that survey, “Even EnterpriseDB, which offers proprietary Oracle-compatible functionality on top of PostgreSQL, is pitched more at Oracle avoidance projects than Oracle replacement projects.”
Back to EnterpriseDB’s survey, and Sam Dean at OStatic has questioned the finding that “only nine percent of respondents said they prefer commercial databases to open source ones”. The answer lies in the question being asked, which was “What prevents you or your company from using an open source database?”.
Clearly the result Sam mentions doesn’t mean that 81% of respondents prefer open source databases, but it does mean that only 9% have a preference for commercial databases that would prevent the use of open source databases.
While 85% indicated that “nothing prohibits their company from using an open source database” likewise that doesn’t mean that 85% are actually using an open source database.
Unfortunately EnterpriseDB didn’t share the result of the question “Have you ever used an open source database in your job or company?”. In the context of this survey, that’s a pretty significant result to leave out.
group
postgresql
postgres
opensource
open-source
matthewaslett
the451group
Marc Liyanage - Software - Mac OS X Packages - PostgreSQL
opensource: del.icio.us tag/opensource
Software
Database
osx
postgresql
reference
postgres
Tutorial
Welcome | PostgreSQL for Mac | Andy Satori
Entity Crisis: Cool Unix Tools
Hyperic Hint #1: Fixing Transaction ID Wraparound Failures in built-in HQDB
The built-in HQ database is PostgreSQL. Recently, users have been discovering PostgreSQL has a certain limitation: it will not execute more than 2 billion transactions between vacuums. In rare cases, an HQ built-in database can get into this state.
If this happens, the database will stop accepting connections and HQ, which needs a data store, will obviously cease to operate properly. The immediate symptom will be that users will not be able to log in to HQ and the message displayed on the screen will be The backend datasource is unavailable.
That error is not enough to say for sure that the problem is PostgreSQL avoiding wraparound failure by not accepting connections. A quick look at the hqdb.log can confirm. The telltale log entries look like this:
FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres"
HINT: Stop the postmaster and use a standalone backend to vacuum database "postgres".
Happily, postgres tells you how to solve the problem. It’s not very specific, though so I’ll add some details.
The first thing to do is immediately shut HQ down (including the built-in database). Next, start just the database in single-user mode. Technically, you only really need to run a VACUUM, but since we’re here, we might as well be thorough and run VACUUM FULL ANALYZE.
I’ve created a script to start the built-in HQ database in single-user mode. It’s a slightly modified version of the db-start.sh script that is included in HQ installations. It takes one argument which is the name of the database to start up. The database name to VACUUM is specified in the hqdb.log message (it is “postgres” in the message above). Start the database with the script and you will get dropped into the psql command line. Run the VACUUM and exit. Looks something like this:
$ bin/db-start-single-user-8.1.sh postgres
PostgreSQL stand-alone backend 8.1.2
backend> VACUUM FULL ANALYZE;
VACUUM
backend>
When it’s done, you send an EOF (usually control-D) to exit the shell and shut down the database. At this point, you’re done and you can start HQ normally. Things will work and will usually perform much faster.
For more information on this PostgreSQL, check their documentation on how to avoid running into it to begin with.