Prior to this commit you would get the cron job installed but to
disable the maintenance cron job you'd have to remove the class
and remove the cron manually.

With the addition of this commit, you can simply set the disable
maintenance parameter to remove the cron job for you.

In the past I've seen the console and puppetdb databases grow
much larger than expected and I have a hypothesis that this is
because the default 20% setting for autovacuum is too high for our
workload.  So, there's a potential that changing this to 5%
might be too low and might reduce performance but it should
reduce disk usage and it can always be tuned upward if the
performance hit is too large, however, it is much more difficult
to reduce the size of a database after it has grown too large.

Basically, I'm erroring on the side of using less disk space and
hopefully less outages due to running out of disk space and we
can open a conversation on performance later if one needs to be had.

Due to an issue where console-services fails to complete about
2 requests after a restart of postgresql, let's go ahead and
restart the console-services service if we restart the postgresql
service.

If the console-services is not on the same node as postgresql then
set all_in_one_pe_install to false and console-services will not
be restarted.

Prior to this commit the parameters were not validated.

After this commit, the parameters are correctly validated.

Due to MODULES-2960 $autovacuum_scale_factor is validated as a float
but then is converted to a string to pass it to the value attribute
of postgresql_conf.

Prior to this commit, these two settings were based on the same
single parameter.

After this commit, the setting have their own dedicated parameter.

In a default install of postgresql the analyze scale factor is .1
and the vacuum scale factor is .2.  I assume the ratio is correct
so when reducing the settings to be more aggressive I keep the
2 to 1 ratio of the settings.

This commit adds the ability to make one cron job per database
to run pg_dump.

I don't particularly like the approach as you have to space out the
cron jobs far enough to make sure they won't overlap but then you
also have lots of wasted time in the middle.

In a future commit, it would be better to have a single script to
perform all the backups and have it run via a single cron job.

Prior to this commit, we only managed autovacuum settings.

After this commit, we manage many more commonly changed postgresql
settings.

We also set autovacuum_cost_delay=0 on the fact_values table of
pe-puppetdb because it prevents bloat of the table and its indexes
if customers have a lot of facts that change every run.

Prior to this commit, you could only manage the settings that were
provided as parameters.

After this commit, you can pass an arbitrary hash of other
postgresql settings you'd like to manage and they will be managed
as well.

Prior to this commit, there was a psql command to change a table
attribute.  This was difficult when trying to point people to an
example that would allow them to do the same for a different table

After this commit, the psql command has been abstracted into a
defined type that makes it easier to set arbitrary table attributes.
A new defined type has been made for the specific case of setting
autovacuum_cost_delay=0

Prior to this commit, there was no backup script.

After this commit, there is a backup script that will iterate
through an array of database names to produce a script to backup
each database.

Using the defined type, you can backup an arbitrary set of
databases on a different cron schedule.

Prior to this commit, a separate backup script was generated for each
database. This commit replaces all of that with a single bash script
that can backup an arbitrary list of databases.

Prior to this commit, the backup functionality was partially inside
init.pp and partially in a defined type.

After this commit, the backup functionality is in its own class
pe_databases::backup.

Prior to this commit, we used ensure_resource because it was meant
to be inside a defined type that may be specified more than once.
Now the defined type is gone and backup is a class

After this commit, we use file resources for clarity since the class
should not be defined more than once.

Prior to this commit, the *_work_mem settings assumed a dedicated
postgresql node.

After this commit, we use whether the node is an all_in_one install
to determine the defaults.

Prior to this commit, the backup script simply backed up but never
worried about preventing the storage of too many backups.

After this commit, the backup script has a retention policy and
deletes more than the desired number of backups minus 1 backups
so that the new backup can be completed.

This will likely cause valid backups to be deleted if the backups
fail and create an empty file.  Then there will be no valid backups
if nothing is done to intervene but we're choosing that option
over running out of disk space by not aggresively deleting backups.

Prior to this commit, we had basic postgresql information in the
README

After this commit, we have specifics around the module and things
you may want to change.  Including how to change the backup
schedule using the provided classes.