Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add pg_repack as default maintenance strategy #25

Merged
merged 4 commits into from Feb 6, 2019
Merged

Conversation

npwalker
Copy link
Contributor

@npwalker npwalker commented Jan 5, 2019

No description provided.

This spec test makes sure that the pg_repack class is included
on versions of PE that support it and is not included on versions
that do not support it.
Copy link
Member

@Sharpie Sharpie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! 👍

$catalogs_tables = '-t catalogs -t catalog_resources -t edges -t certnames"'
$other_tables = '-t producers -t resource_params -t resource_params_cache"'
$reports_tables = '-t reports"'
$logging = "> ${logging_directory}/output.log 2>&1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any logic to ensure that multiple repacks cannot be started simultaneously? That's the biggest danger of automated repacking.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only ones that could overlap are the other tables and the reports table which run at 5:30 on 1 day of the month while facts and catalogs run at 4:30 2 days a week.

I'm not particularly concerned about them overlapping... but if we thought it was a serious concern then we could move the times they run further apart.

$ensure_cron = $disable_maintenace ? {
true => absent,
default => present
#If the PE Version includes pg_repack (2018.1.7 and 2019.0.2) then use pg_repack and remove the old script and cron jobs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this instead check something more direct than PE Version, such as the existence of pg_repack itself?

Then, this module could be used with manual installs of pg_repack in older versions of PE.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Untested:

Facter.add(:pg_repack) do
  confine Facter.value(:pe_postgresql_info)['installed_server_version'] => '9.6'
  setcode do
    cmd = %q(su - pe-postgres -s /bin/bash -c "/opt/puppetlabs/server/bin/psql -d pe-puppetdb -c 'SELECT * FROM pg_extension'")
    res = Facter::Util::Resolution.exec(cmd)
    res.include?('pg_repack')
  end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if someone really wants to use pg_repack on an older version of PE they can set manage_database_maintenance to false and then include the pg_repack manifest via a profile.

I don't suspect the use of manually installed pg_repack will be high in older installs.

@npwalker npwalker merged commit 6a52fb6 into master Feb 6, 2019
@tkishel tkishel deleted the use_pg_repack branch February 18, 2020 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants