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
Since facter 2.2.0 'fixed' the lsbmajdistrelease fact for Ubuntu, we now have to regexp
for the value. The new value would be '10.04' whereas the old is '10'.
Signed-off-by: Ken Barber <ken@bob.sh>
I'd like to see this patch included ASAP -- the desirable default could
be manage_pg_ident_conf => true, but one could already manage this file
manually : we don't want to wipe it.
Please switch the default from false to true at the next major release
and write a line about this in the release notes.
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.
