Bug 2006602

Description of problem:

This patch here from 2016 and done due to BZ1340722:

  core: move guest memory related fields to statistics

It moved the statistics of the VM from vm_dynamic to vm_statistics, but it broke the types.
Both guest_mem_cached and guest_mem_buffered are affected.

For example, for guest_mem_cached, it deleted from vm_dynamic and added to vm_statistics

packaging/dbscripts/upgrade/04_01_0040_move_guest_mem_fields_to_statistics.sql
SELECT fn_db_drop_column('vm_dynamic', 'guest_mem_cached');
SELECT fn_db_add_column('vm_statistics', 'guest_mem_cached', 'INTEGER DEFAULT NULL');

But it added as INTEGER to vm_statistics, this was BIGINT before on vm_dynamic.

$ grep guest_mem_cached packaging/dbscripts/create_tables.sql
    guest_mem_cached bigint,

The function that updates the statistics still uses bigint correctly:

CREATE OR REPLACE FUNCTION UpdateVmStatistics (
    v_cpu_sys DECIMAL(18, 0),
    v_cpu_user DECIMAL(18, 0),
    v_elapsed_time DECIMAL(18, 0),
    v_usage_cpu_percent INT,
    v_usage_mem_percent INT,
    v_usage_network_percent INT,
    v_disks_usage TEXT,
    v_vm_guid UUID,
    v_guest_mem_buffered BIGINT,
    v_guest_mem_cached BIGINT        <------------
    )

But the actual table has INTEGER type now:

engine=# \d vm_statistics
                           Table "public.vm_statistics"
        Column         |           Type           | Collation | Nullable | Default 
-----------------------+--------------------------+-----------+----------+---------
 vm_guid               | uuid                     |           | not null | 
 cpu_user              | numeric(18,0)            |           |          | 0
 cpu_sys               | numeric(18,0)            |           |          | 0
 usage_mem_percent     | integer                  |           |          | 0
 usage_cpu_percent     | integer                  |           |          | 0
 disks_usage           | text                     |           |          | 
 _update_date          | timestamp with time zone |           |          | 
 guest_mem_buffered    | integer                  |           |          | 
 guest_mem_cached      | integer                  |           |          |         <---------------
 usage_network_percent | smallint                 |           |          | 0
 elapsed_time          | numeric(18,0)            |           |          | 0
Indexes:
    "pk_vm_statistics" PRIMARY KEY, btree (vm_guid)
Foreign-key constraints:
    "vm_static_vm_statistics" FOREIGN KEY (vm_guid) REFERENCES vm_static(vm_guid) ON DELETE CASCADE

So when we have a big VM with lots of cached memory, we get this, as it won't fit on an integer

2021-09-21 04:00:08,904+02 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-67) [] Exception:: org.springframework.dao.DataIntegrityViolationException: ConnectionCallback; ]; Batch entry 0 select * from public.updatevmstatistics(CAST (0.8 AS numeric),CAST (38.61 AS numeric),CAST (314053.0 AS numeric),CAST (0 AS int4),CAST (3 AS int4),CAST (3 AS int4),CAST ('[]' AS text),CAST ('eec0bb72-92eb-464e-8545-ab0a6f3949a6'::uuid AS uuid),CAST (393296 AS int8),CAST (3222083280 AS int8)) as result was aborted: ERROR: integer out of range
  Where: SQL statement "UPDATE vm_statistics
    SET cpu_sys = v_cpu_sys,
        cpu_user = v_cpu_user,
        elapsed_time = v_elapsed_time,
        usage_cpu_percent = v_usage_cpu_percent,
        usage_mem_percent = v_usage_mem_percent,
        usage_network_percent = v_usage_network_percent,
        disks_usage = v_disks_usage,
        guest_mem_buffered = v_guest_mem_buffered,
        guest_mem_cached = v_guest_mem_cached,
        _update_date = LOCALTIMESTAMP
    WHERE vm_guid = v_vm_guid"
PL/pgSQL function updatevmstatistics(numeric,numeric,numeric,integer,integer,integer,text,uuid,bigint,bigint) line 3 at SQL statement  Call getNextException to see other errors in the batch.; nested exception is java.sql.BatchUpdateException: Batch entry 0 select * from public.updatevmstatistics(CAST (0.8 AS numeric),CAST (38.61 AS numeric),CAST (314053.0 AS numeric),CAST (0 AS int4),CAST (3 AS int4),CAST (3 AS int4),CAST ('[]' AS text),CAST ('eec0bb72-92eb-464e-8545-ab0a6f3949a6'::uuid AS uuid),CAST (393296 AS int8),CAST (3222083280 AS int8)) as result was aborted: ERROR: integer out of range
  Where: SQL statement "UPDATE vm_statistics
    SET cpu_sys = v_cpu_sys,
        cpu_user = v_cpu_user,
        elapsed_time = v_elapsed_time,
        usage_cpu_percent = v_usage_cpu_percent,
        usage_mem_percent = v_usage_mem_percent,
        usage_network_percent = v_usage_network_percent,
        disks_usage = v_disks_usage,
        guest_mem_buffered = v_guest_mem_buffered,
        guest_mem_cached = v_guest_mem_cached,
        _update_date = LOCALTIMESTAMP
    WHERE vm_guid = v_vm_guid"

3222083280 = 3,222,083,280, which is higher than 2,147,483,647.

Version-Release number of selected component (if applicable):
rhvm-4.4.8.5-0.4.el8ev.noarch

How reproducible:
Always

Steps to Reproduce:

execute the same function with the values above:
engine=# select * from public.updatevmstatistics(CAST (0.8 AS numeric),CAST (38.61 AS numeric),CAST (314053.0 AS numeric),CAST (0 AS int4),CAST (3 AS int4),CAST (3 AS int4),CAST ('[]' AS text),CAST ('eec0bb72-92eb-464e-8545-ab0a6f3949a6'::uuid AS uuid),CAST (393296 AS int8),CAST (3222083280 AS int8));
ERROR:  integer out of range

Actual results:
* vm_statistics not updated, logs flooded with errors

Expected results:
* vm_statistics updated