below covers various concepts around "Ansible and PostgreSQL" - something I am very enthusiastic about.
This presentation covers the following topics:
Overview of Ansible and PostgreSQL
Best strategies for mixed cloud and on-premises deployments
How to deploy AlwaysOn PostgreSQL clusters
How to perform maintenance updates
How to create a variety of cluster types
How to backup servers for mixed on-premises and multi-cloud deployments
I don’t often get to speak on technical topics, but the video of my
or if you just decided to encrypt the sensitive stuff. You need to do the encryption right and actually protecting the information in both cases. Unfortunately, full-disk-encrytion and pgcrypto are not a good fit for multiple reasons, and application-level encryption reduces the database to "dumb" storage. Let's look at an alternative approach - offloading the encryption to a separate trusted component, implemented as a custom data type.
Let's assume you have some sensitive data, that you need to protect by encryption. It might be credit card numbers (the usual example), social security numbers, or pretty much anything you consider sensitive. It does not matter if the encryption is mandated by a standard like
A database management tool that simplifies what is complex and drives performance. OmniDB is one such tool with which you can connect to several different databases - including PostgreSQL, Oracle, MySQL and others.
2ndQuadrant recently hosted a webinar on this very topic: Introduction to OmniDB. The webinar was presented by OmniDB co-founders and PostgreSQL consultants at 2ndQuadrant, Rafael Castro & William Ivanski.
The recording of the webinar is now available here.
Questions that Rafael and William couldn’t respond to during the live webinar have been answered below.
Q1: There are other open source GUI tools around to manage PostgreSQL. Why are you investing efforts on a new tool?
A1: When OmniDB was created we wanted a web tool, and not all available tools
UUIDs are a popular identifier data type - they are unpredictable, and/or globally unique (or at least very unlikely to collide) and quite easy to generate. Traditional primary keys based on sequences won't give you any of that, which makes them unsuitable for public identifiers, and UUIDs solve that pretty naturally.
But there are disadvantages too - they may make the access patterns much more random compared to traditional sequential identifiers, cause WAL write amplification etc. So let's look at an extension generating "sequential" UUIDs, and how it can reduce the negative consequences of using UUIDs.
Announcing Release 9 of the PostgreSQL Buildfarm client.
Along with numerous fixes of minor bugs and a couple of not so minor bugs, this release has the following features:
new command line parameter --run-parallel for run_branches.pl runs
all branches in parallel, possibly across animals as well
new config setting max_load_avg inhibits a run if the load average
is higher than the setting
new config_option archive_reports saves that number of generations
of the report sent to the server
new command line parameter --show-error-log which outputs the error
log if any on stdout
automatically rerun 3 hours after a git failure, useful on back
branches where commits can be infrequent
automatically convert old pgbuildfarm.org URLs to
PostgreSQL 11 was released recently, with exciting new features. One of them is the ability to write SQL procedures that can perform full transaction management, enabling developers to create more advanced server-side applications. SQL procedures can be created using the CREATE PROCEDURE command and executed using the CALL command. Since OmniDB 2.3.0 it is possible to debug PostgreSQL PL/pgSQL functions. Support to PostgreSQL 11 functions and procedures was added in OmniDB 2.11.0.
Last week we released OmniDB 2.12.0 with nice new features and a new revamped visual, so I'm going to show you how OmniDB 2.12.0 can debug PostgreSQL 11 procedures.
First of all, if you have not done that already, download and install a binary PostgreSQL library called omnidb_plugin and enable it in
PostgreSQL is referred to as "The world’s most advanced open source database" - but what does PostgreSQL have that other open source relational databases don't?
2ndQuadrant recently hosted a webinar on this very topic: PostgreSQL is NOT your traditional SQL database, presented by Gülçin Yıldırım Jelínek, Cloud Services Manager at 2ndQuadrant.
The recording of the webinar is now available here.
Questions that Gülçin couldn’t respond to during the live webinar have been answered below.
Q1: What exactly is the role of postgresql for a marketplace like ebay or rakuten?
A1: This question is not very clear. If the question is about whether Postgres can be used in an e-commerce website, the answer is yes.
Q2: I'm in process of switching from MS SQL
During the PostgreSQL 11 development cycle an impressive amount of work was done to improve table partitioning. Table partitioning is a feature that has existed in PostgreSQL for quite a long time, but it really wasn't until version 10 that it started to become a highly useful feature. We'd previously claimed that table inheritance was our implementation of partitioning, which was true. It just left you to do much of the work yourself manually. For example, during INSERTs, if you wanted the tuples to make it to your partitions then you had to set up triggers to do that for you. Inheritance partitioning was also slow and hard to develop additional features on top of.
In PostgreSQL 10 we saw the birth of "Declarative Partitioning", a feature which is designed to solve many of the
In PostgreSQL version 10 or less, if you add a new column to a table without specifying a default value then no change is made to the actual values stored. Any existing row will just fill in a NULL for that column. But if you specify a default value, the entire table gets rewritten with the default value filled in on every row. That rewriting behavior changes in PostgreSQL 11.
In a new feature I worked on and committed, the default value is just stored in the catalog and used where needed in rows existing at the time the change was made. New rows, and new versions of existing rows, are written with the default value in place, as happens now. Any row that doesn't have that column must have existed before the table change was made, and uses this value stored in the catalog when the row is
After the success of last year's event, the second PGDay held in Australia, we're back this year with PGDay Down Under. The name “Down Under” refers to Australia and New Zealand, due to the fact these countries are located in the lower latitudes of the southern hemisphere.
The conference is a one-day community event organized by the newborn PostgreSQL Down Under Incorporated (also known as PGDU), a not-for-profit association established to support the growth and learning of PostgreSQL, the world’s most advanced open source database, in Australia and New Zealand.
PGDay Down Under aims to satisfy a large audience of PostgreSQL users and enthusiasts by selecting a wide range of talks and presentations that are of interest to:
Database administrators that are already using