FYI,
I just did an "apt-get update; apt-get dist-upgrade" on an Ubuntu
18.04 perfsonar instance, to upgrade from 4.2.0 to 4.2.1.
It broke with this error during the database upgrade:
│ An error occurred while upgrading the
database:
│
│
│
│ NOTICE: drop cascades to 2 other objects DETAIL: drop
cascades to view heartbeat_full drop cascades to view
heartbeat_json │
│ NOTICE: drop cascades to 3 other objects DETAIL: drop
cascades to view schedule_upcoming drop cascades to
view │
│ schedule_runs_to_schedule drop cascades to function
api_proposed_times(uuid,timestamp with time zone,timestamp with
time │
│ zone,integer) NOTICE: view "heartbeat_full" does not
exist, skipping NOTICE: trigger "context_alter_post" for
relation │
│ "context" does not exist, skipping NOTICE: drop
cascades to trigger task_alter_notify_update on table task
NOTICE: drop │
│ cascades to 4 other objects DETAIL: drop cascades to
default for table run column state drop cascades to index
run_current │
│ drop cascades to view run_status drop cascades to view
run_status_short NOTICE: drop cascades to 2 other objects
DETAIL: │
│ drop cascades to view run_conflictable drop cascades
to view schedule_overlap NOTICE: view "run_conflictable" does
not │
│ exist, skipping ERROR: must be owner of function
run_can_proceed CONTEXT: SQL statement "DROP FUNCTION
run_can_proceed(int8) │
│ CASCADE;" PL/pgSQL function
drop_function_all(text) line 34 at EXECUTE SQL statement
"SELECT │
│ drop_function_all('run_can_proceed')"
PL/pgSQL function inline_code_block line 1 at
PERFORM │
│
│
│ Fortunately, should hold a backup of the database,
made just before the upgrade (unless the error occurred during
backup │
│ creation, in which case no changes will have been
applied yet). Your options
are: │
│ * abort - Causes the operation to fail; you will need
to
downgrade,
│
│ reinstall, reconfigure this package, or otherwise
manually
intervene
│
│ to continue using it. This will usually also impact
your ability
to │
│ install other packages until the installation
failure is
resolved.
│
│ * retry - Prompts once more with all the
configuration
questions
│
│ (including ones you may have missed due to the
debconf
priority
│
│ setting) and makes another attempt at performing
the
operation.
│
│ * retry (skip questions) - Immediately attempts the
operation
again, │
│ skipping all questions. This is normally useful
only if you
have │
│ solved the underlying problem since the time the
error
occurred.
│
│ * ignore - Continues the operation ignoring
dbconfig-common
errors.
│
│ This will usually leave this package without a
functional database.
As an attempted workaround, I did the following in another
window:
sudo su - postgres -c 'psql pscheduler'
DROP FUNCTION run_can_proceed(int8) CASCADE;
\q
and then selected "retry (skip questions)". The upgrade then
proceeded, although it ended with this warning:
...
update-initramfs: deferring update (trigger activated)
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for initramfs-tools (0.130ubuntu3.8)
...
Processing triggers for pscheduler-server (4.2.1-1) ...
W: APT had planned for dpkg to do more than it reported
back (433 vs 437).
Affected packages: pscheduler-server:amd64
Whether my database is in a broken state now I don't know -
although I can at least see that the run_can_proceed function has
been recreated:
pscheduler=# \df run_can_proceed
List of functions
Schema | Name | Result data type | Argument
data types | Type
--------+-----------------+------------------+---------------------+--------
public | run_can_proceed | boolean | run_id
bigint | normal
(1 row)
Anyway, I thought this was worth reporting.
Regards,
Brian.
