From c3bbbc35c49c109a49d7b8f18eb591853117fb8e Mon Sep 17 00:00:00 2001 From: Craig Comstock Date: Tue, 15 Oct 2024 13:06:33 -0500 Subject: [PATCH 1/2] Adjusted hub upgrade database migration to show only actionable logs If pg_upgrade fails it is OK because we have several other options which we try during hub package upgrade. To see any errors, run the upgrade with DEBUG=1 defined as an environment variable. Ticket: ENT-12383 Changelog: title --- packaging/common/cfengine-hub/postinstall.sh | 21 ++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/packaging/common/cfengine-hub/postinstall.sh b/packaging/common/cfengine-hub/postinstall.sh index 9189d1e75..14739af46 100644 --- a/packaging/common/cfengine-hub/postinstall.sh +++ b/packaging/common/cfengine-hub/postinstall.sh @@ -706,16 +706,25 @@ do_migration() { cd /tmp cf_console echo "Migrating database using pg_upgrade utility..." cf_console echo - if migrate_db_using_pg_upgrade && [ $DEBUG -lt 1 ]; then + _pg_upgrade_log="/tmp/cfengine_pg_upgrade.log" + migrate_db_using_pg_upgrade >"${_pg_upgrade_log}" 2>&1 + rc=$? + if [ $rc -eq 0 ] && [ $DEBUG -lt 1 ]; then # Succeeded + cat "${_pg_upgrade_log}" # might as well see the details of how it worked + rm "${_pg_upgrade_log}" # clean up exit 0 # exits only from (...) fi cf_console echo "Migration using pg_upgrade failed." - # here pg_upgrade probably said something like - # Consult the last few lines of "/var/cfengine/state/pg/data/pg_upgrade_output.d/20230913T150025.959/log/pg_upgrade_server.log" for the probable cause of the failure. - cf_console echo "Showing last lines of any related log files:" - _daysearch=$(date +%Y%m%d) - find "$PREFIX"/state/pg/data/pg_upgrade_output.d -name '*.log' | grep "$_daysearch" | cf_console xargs tail + if [ $DEBUG -gt 0 ]; then + cat "${_pg_upgrade_log}" + rm "${_pg_upgrade_log}" + # pg_upgrade probably said something like + # Consult the last few lines of "/var/cfengine/state/pg/data/pg_upgrade_output.d/20230913T150025.959/log/pg_upgrade_server.log" for the probable cause of the failure. + cf_console echo "Showing last lines of any related log files:" + _daysearch=$(date +%Y%m%d) + find "$PREFIX"/state/pg/data/pg_upgrade_output.d -name '*.log' | grep "$_daysearch" | cf_console xargs tail + fi cf_console echo check_disk_space # will abort if low on disk space init_postgres_dir "$new_pgconfig_file" "$pgconfig_type" From 2c74496294cf53b924bb93a1cd0b30b98935d726 Mon Sep 17 00:00:00 2001 From: Craig Comstock Date: Wed, 16 Oct 2024 14:36:02 -0500 Subject: [PATCH 2/2] Revert "Adjusted calling pg_upgrade during upgrade to include LD_LIBRARY_PATH of previous installation" In the case of 3.21.5 (postgresql 15.6) to 3.25.0a (master, postgresql 17.0) pg_upgrade seems to work fine with the removal of LD_LIBRARY_PATH pointed at the backup. In other cases we will simply ignore pg_upgrade failures and allow the subsequent migration methods to proceed. This reverts commit e39924ca2926a495320b5705e9c2886fea06f6b4. --- packaging/common/cfengine-hub/postinstall.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packaging/common/cfengine-hub/postinstall.sh b/packaging/common/cfengine-hub/postinstall.sh index 14739af46..f90fe108b 100644 --- a/packaging/common/cfengine-hub/postinstall.sh +++ b/packaging/common/cfengine-hub/postinstall.sh @@ -525,7 +525,7 @@ check_disk_space() { # and then importing it into new one migrate_db_using_pg_upgrade() { - su cfpostgres -c "LD_LIBRARY_PATH=$BACKUP_DIR/lib/ $PREFIX/bin/pg_upgrade --old-bindir=$BACKUP_DIR/bin --new-bindir=$PREFIX/bin --old-datadir=$BACKUP_DIR/data --new-datadir=$PREFIX/state/pg/data" + su cfpostgres -c "$PREFIX/bin/pg_upgrade --old-bindir=$BACKUP_DIR/bin --new-bindir=$PREFIX/bin --old-datadir=$BACKUP_DIR/data --new-datadir=$PREFIX/state/pg/data" } migrate_db_using_pipe() {