Prior to this commit, when creating databases with a name or owner that has
characters which must be quoted (e.g., "pe-postgres"), the postgresql::server::database define
fails due to a SQL syntax error.
Adds connection-settings (for remote DB support) when creating DB resources.
Connection-settings allows a hash of options that can be used
when connecting the a remote DB (such as PGHOST, PGPORT, PGPASSWORD
PGSSLKEY) and a special option DBVERSION indicating the version
of the remote database.
Including
- Puppet updates
- Documentation updates
- RSpec unit test updates
- RSpec acceptance test updates
- Some test coverage for connection-settings
- Working acceptance test...
Basic vagrant setup:
* Two boxes, server and client
* Runs puppet code to on server to setup a postgres server that allows all connections and md5 connections, creates db puppet to look at
* Runs puppet code on client to make a server that a psql command can be run against puppet db on other server
* Does some fancy stuff to get the fact of the IP from the first server to connect to
- Backwards compatible, with deprecation warnings around old parameters
This allows you to use `postgres_pqsl` commands to be run against a specified host. The ultimate goal being that you can use `puppetlabs-postsgresql` to run against remote instances, especially things such as Amazons RDS service.
This PR will be further extended to do things like allow remote `table_grant` and the like.
On psql 8.1, `pg_catalog.shobj_description` does not exist. Also, if the
database to comment is not the current db then this warning will be
raised and the comment will not be applied: `WARNING: database comments
may only be applied to the current database`
This fix uses the pg_* databases to find the comment based on the
database oid rather than the shared object description function.
The change introduced in b781849882 added
a complex operation that was not handled correctly for all operating
systems. This fix includes the following corrections:
- Change the systemd config and reload systemd for datadir changes in
RHEL 7, and move configuration for this into
postgresql::server::config since it is managing both the PGDATA and
PGPORT variables
- Make sure Debian systems stop the service before changing the datadir
- Recreate cert links after running initdb in Debian and early ubuntu
- Change the port in the port spec to avoid selinux issues
- Turn off selinux in pgdata spec to avoid selinux issues
- Correct syntax for describing presence of a directory in pgdata spec
- Move the pgdata spec to the end of the tests so that puppet doesn't
have to manager purging and recreating the original datadir
- Update README to describe all caveats of using this parameter
Ensure that data_directory is set in the config. per GitHub user tbd - PR#510 / PR#494 that was filed against wrong module branch"
Adds acceptance test for non default PGDATA, based on alternative_port_spec.rb
Fixes unit test for data directory
This defined type helps create database schemas, and assign them to an
`owner`. It is closely modeled after Postgresql::Server::Tablespace.
It uses PostgreSQL's builtin IF NOT EXISTS to guarantee idempotency.
(>= 9.3, else it checks pg_namespace).
n.b.: This defined type *requires* that a `db` is passed. This is a
concious design decision, since we find it rather useless to create such
schemas in the default `postgres` database, and if *were* useful, one
can always "over-specify".
This addresses MODULES-1098.
This doesn't fix the root cause of the issue, such as the fact that
dpkg can't do wildcard removals, and the uninstall fails when you're
passing in a version number like this, but THIS test doesn't care, it
just wants to make sure the deprecation warning appears in the first
place.
This does however make the tests pass on 14.04.
Interactions between resource refreshes and the 'unless' parameter have been
fixed to follow the behaviour of the 'exec' type.
The 'unless' parameter is now always taken into account, whether in ordinary
operation, during a refresh, or when refreshonly is set to true. The resource
will not run the SQL command when the 'unless' clause matches a row.
Previously a refresh on a resource would ignore the 'unless' parameter if set
which could cause a failure re-running a command, such as attempting to create
a role that already exists.
The following examples have been fixed:
* should not run SQL when refreshed and the unless query returns rows
* with refreshonly should not run SQL when the unless query returns no rows
* with refreshonly should not run SQL when refreshed and the unless query
returns rows
This is done by moving the logic for refreshonly and whether to run the SQL
command from the provider into the type, and consolidating it in the
should_run_sql method which is called during 'command' property retrieval
(instead of sync) and during refresh.
