Re: [ovirt-users] after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi@redhat.com> a écrit :
On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
https://www.dropbox.com/s/70h2ajt049i89p6/ovirt-engine.log.tar.gz?dl=0
Seems like this wasn't the first error. Before that, the engine lost connection to the database:
Later the engine was restarted and then the error you reported.
Are you sure your database is ok?
Of course I needed to restart the database, to change the requested setting about vacuum. But it was a scheduled restart, not during the upgrade.
Please provide the output of 'pg_dump -s' for it, and the output of 'select * from schema_version'.
it ? what it's name. I have no knowledge of pg, how can I connect to it to give the requested informations.
Can you please describe the full flow that you went through?
On last friday, I tried a first upgrade, but it stop because of the requested version mismatch. So I stopped it and asked for help. On monday I tried to apply the tuning on my database about autovacuum and so restart it. At this time, ovirt was still working fine. I then upgraded the pg client, to match pg_dump with the server but not the jdbc library, to keep the one supported (9.2). And then it failed and didn't want to restart any more.
On Tue, Apr 25, 2017 at 11:14 AM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi@redhat.com> a écrit :
On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
https://www.dropbox.com/s/70h2ajt049i89p6/ovirt-engine.log.tar.gz?dl=0
Seems like this wasn't the first error. Before that, the engine lost connection to the database:
Later the engine was restarted and then the error you reported.
Are you sure your database is ok?
Of course I needed to restart the database, to change the requested setting about vacuum. But it was a scheduled restart, not during the upgrade.
Please provide the output of 'pg_dump -s' for it, and the output of 'select * from schema_version'.
it ? what it's name. I have no knowledge of pg, how can I connect to it to give the requested informations.
Sorry, I was under the impression that your organization has some pg expertise, based on the thread about remote version. On the pg machine, this should work: su - postgres -c 'pg_dump -s engine' > engine-schema.dump su - postgres -c 'psql engine -c "select * from schema_version;"' > schema-version-table To do this from the engine machine, you'd need to pass more options to supply the credentials. You can find those that you use for the engine in /etc/ovirt-engine/engine.conf.d/10-setup-database.conf .
Can you please describe the full flow that you went through?
On last friday, I tried a first upgrade, but it stop because of the requested version mismatch. So I stopped it and asked for help.
On monday I tried to apply the tuning on my database about autovacuum and so restart it.
At this time, ovirt was still working fine.
I then upgraded the pg client, to match pg_dump with the server but not the jdbc library, to keep the one supported (9.2).
Please explain this last part with more details. IIUC your pg client was 9.4.8, and now it's 9.4.11. Please share yum logs (or whatever you have if you installed it not using yum). Please share all engine-setup logs. I think the engine should work just fine with pg 9.5 (Fedora 25's default). Never heard about using 9.4.
And then it failed and didn't want to restart any more.
So all was good until you changed (downgraded?) your pg client? So perhaps try to revert that. Although if you didn't change your jdbc library, I do not think this should have affected you. But in any case, if the failure was not caused by running 'engine-setup', it's most likely not due to a bug in engine-setup, but elsewhere. Best, -- Didi
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi@redhat.com> a écrit :
On Tue, Apr 25, 2017 at 11:14 AM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi@redhat.com> a écrit :
On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
https://www.dropbox.com/s/70h2ajt049i89p6/ovirt-engine.log.tar.gz?dl=0
Seems like this wasn't the first error. Before that, the engine lost connection to the database:
Later the engine was restarted and then the error you reported.
Are you sure your database is ok?
Of course I needed to restart the database, to change the requested setting about vacuum. But it was a scheduled restart, not during the upgrade.
Please provide the output of 'pg_dump -s' for it, and the output of 'select * from schema_version'.
it ? what it's name. I have no knowledge of pg, how can I connect to it to give the requested informations.
Sorry, I was under the impression that your organization has some pg expertise, based on the thread about remote version.
On the pg machine, this should work: su - postgres -c 'pg_dump -s engine' > engine-schema.dump su - postgres -c 'psql engine -c "select * from schema_version;"' > schema-version-table
https://www.dropbox.com/s/6o51owq0f6qrdte/schema-version-table?dl=0 https://www.dropbox.com/s/luw35rlcksl3uwa/engine-schema.dump?dl=0
Can you please describe the full flow that you went through?
On last friday, I tried a first upgrade, but it stop because of the requested version mismatch. So I stopped it and asked for help.
On monday I tried to apply the tuning on my database about autovacuum and so restart it.
At this time, ovirt was still working fine.
I then upgraded the pg client, to match pg_dump with the server but not the jdbc library, to keep the one supported (9.2).
Please explain this last part with more details.
IIUC your pg client was 9.4.8, and now it's 9.4.11.
Please share yum logs (or whatever you have if you installed it not using yum). Please share all engine-setup logs.
grep -i postgres /var/log/yum.log Apr 24 13:28:00 Updated: postgresql94-libs-9.4.11-2PGDG.rhel7.x86_64 Apr 24 13:28:01 Updated: postgresql94-9.4.11-2PGDG.rhel7.x86_64 Apr 24 13:28:07 Updated: postgresql-jdbc-42.0.0-1.rhel7.noarch Apr 24 13:28:09 Updated: postgresql94-server-9.4.11-2PGDG.rhel7.x86_64 Apr 24 13:36:48 Installed: collectd-postgresql-5.7.0-2.el7.x86_64 rpm -qa |grep -i postgres postgresql94-libs-9.4.11-2PGDG.rhel7.x86_64 postgresql94-server-9.4.11-2PGDG.rhel7.x86_64 postgresql-jdbc-42.0.0-1.rhel7.noarch collectd-postgresql-5.7.0-2.el7.x86_64 postgresql94-9.4.11-2PGDG.rhel7.x86_64
I think the engine should work just fine with pg 9.5 (Fedora 25's default). Never heard about using 9.4.
And then it failed and didn't want to restart any more.
So all was good until you changed (downgraded?) your pg client? So
I upgraded the client from 9.4.8 to 9.4.11, since my server was already 9.4.11, downloaded directly from postgres' yum repo : https://yum.postgresql.org/repopackages.php
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi@redhat.com> a écrit :
So all was good until you changed (downgraded?) your pg client? So perhaps try to revert that. Although if you didn't change your jdbc library, I do not think this should have affected you. But in any case, if the failure was not caused by running 'engine-setup', it's most likely not due to a bug in engine-setup, but elsewhere.
Possible, but for the moment, I need a way to get out of this trap. My ovirt engine is broken.
On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi@redhat.com> a écrit :
So all was good until you changed (downgraded?) your pg client? So perhaps try to revert that. Although if you didn't change your jdbc library, I do not think this should have affected you. But in any case, if the failure was not caused by running 'engine-setup', it's most likely not due to a bug in engine-setup, but elsewhere.
Possible, but for the moment, I need a way to get out of this trap. My ovirt engine is broken.
Your db dump does have gettagsbyparent_id, so that's not the problem. I am not an expert in the engine side, no idea otherwise. My guess is that it might be related to: 2017-04-24 16:52:23,700+02 WARN [org.springframework.jdbc.core.metadata.CallMetaDataProvider] (ServerService Thread Pool -- 49) Error while retrieving metadata for procedure columns: org.postgresql.util.PSQLException: Cannot cast type String to boolean: "2" 2017-04-24 16:52:23,727+02 WARN [org.springframework.jdbc.core.metadata.CallMetaDataProvider] (ServerService Thread Pool -- 53) Error while retrieving metadata for procedure columns: org.postgresql.util.PSQLException: Cannot cast type String to boolean: "2" 2017-04-24 16:52:23,759+02 WARN [org.springframework.jdbc.core.metadata.CallMetaDataProvider] (ServerService Thread Pool -- 49) Error while retrieving metadata for procedure columns: org.postgresql.util.PSQLException: Cannot cast type String to boolean: "2" Perhaps try to start the engine with DEBUG level info to get more info. Edit /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.xml.in and replace each 'INFO' with 'DEBUG', then restart the engine. Adding Eli. Best, -- Didi
Le 25 avr. 2017 à 12:05, Yedidyah Bar David <didi@redhat.com> a écrit :
On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi@redhat.com> a écrit :
So all was good until you changed (downgraded?) your pg client? So perhaps try to revert that. Although if you didn't change your jdbc library, I do not think this should have affected you. But in any case, if the failure was not caused by running 'engine-setup', it's most likely not due to a bug in engine-setup, but elsewhere.
Possible, but for the moment, I need a way to get out of this trap. My ovirt engine is broken.
Your db dump does have gettagsbyparent_id, so that's not the problem. I am not an expert in the engine side, no idea otherwise.
But: su - postgres $ psql ovirt_engine psql (9.4.11) Type "help" for help. ovirt_engine=# select * from getallmacpoolrangesbymacpoolid(); ERROR: function getallmacpoolrangesbymacpoolid() does not exist LINE 1: select * from getallmacpoolrangesbymacpoolid(); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts.
On Tue, Apr 25, 2017 at 1:14 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 12:05, Yedidyah Bar David <didi@redhat.com> a écrit :
On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi@redhat.com> a écrit :
So all was good until you changed (downgraded?) your pg client? So perhaps try to revert that. Although if you didn't change your jdbc library, I do not think this should have affected you. But in any case, if the failure was not caused by running 'engine-setup', it's most likely not due to a bug in engine-setup, but elsewhere.
Possible, but for the moment, I need a way to get out of this trap. My ovirt engine is broken.
Your db dump does have gettagsbyparent_id, so that's not the problem. I am not an expert in the engine side, no idea otherwise.
But:
su - postgres $ psql ovirt_engine psql (9.4.11) Type "help" for help.
ovirt_engine=# select * from getallmacpoolrangesbymacpoolid(); ERROR: function getallmacpoolrangesbymacpoolid() does not exist LINE 1: select * from getallmacpoolrangesbymacpoolid(); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts.
Because it requires a uuid parameter. -- Didi
I activated pg query log and got that: grep gettagsbyparent_id /data/pgsql/9.4/data/pg_log/postgresql-Tue.log < 2017-04-25 12:21:29.770 CEST >LOG: execute <unnamed>: SELECT NULL AS PROCEDURE_CAT, n.nspname AS PROCEDURE_SCHEM, p.proname AS PROCEDURE_NAME, NULL, NULL, NULL, d.description AS REMARKS, 2 AS PROCEDURE_TYPE, p.proname || '_' || p.oid AS SPECIFIC_NAME FROM pg_catalog.pg_namespace n, pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_description d ON (p.oid=d.objoid) LEFT JOIN pg_catalog.pg_class c ON (d.classoid=c.oid AND c.relname='pg_proc') LEFT JOIN pg_catalog.pg_namespace pn ON (c.relnamespace=pn.oid AND pn.nspname='pg_catalog') WHERE p.pronamespace=n.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'gettagsbyparent_id' ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, p.oid::text < 2017-04-25 12:21:29.787 CEST >LOG: execute <unnamed>: SELECT n.nspname,p.proname,p.prorettype,p.proargtypes, t.typtype,t.typrelid, p.proargnames, p.proargmodes, p.proallargtypes, p.oid FROM pg_catalog.pg_proc p, pg_catalog.pg_namespace n, pg_catalog.pg_type t WHERE p.pronamespace=n.oid AND p.prorettype=t.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'gettagsbyparent_id' ORDER BY n.nspname, p.proname, p.oid::text < 2017-04-25 12:21:29.827 CEST >ERROR: function gettagsbyparent_id() does not exist at character 16 < 2017-04-25 12:21:29.827 CEST >STATEMENT: select * from gettagsbyparent_id() And: grep getallmacpoolrangesbymacpoolid /data/pgsql/9.4/data/pg_log/postgresql-Tue.log < 2017-04-25 12:13:03.519 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:13:03.519 CEST >STATEMENT: select * from getallmacpoolrangesbymacpoolid(); < 2017-04-25 12:21:29.816 CEST >LOG: execute <unnamed>: SELECT NULL AS PROCEDURE_CAT, n.nspname AS PROCEDURE_SCHEM, p.proname AS PROCEDURE_NAME, NULL, NULL, NULL, d.description AS REMARKS, 2 AS PROCEDURE_TYPE, p.proname || '_' || p.oid AS SPECIFIC_NAME FROM pg_catalog.pg_namespace n, pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_description d ON (p.oid=d.objoid) LEFT JOIN pg_catalog.pg_class c ON (d.classoid=c.oid AND c.relname='pg_proc') LEFT JOIN pg_catalog.pg_namespace pn ON (c.relnamespace=pn.oid AND pn.nspname='pg_catalog') WHERE p.pronamespace=n.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'getallmacpoolrangesbymacpoolid' ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, p.oid::text < 2017-04-25 12:21:29.821 CEST >LOG: execute <unnamed>: SELECT n.nspname,p.proname,p.prorettype,p.proargtypes, t.typtype,t.typrelid, p.proargnames, p.proargmodes, p.proallargtypes, p.oid FROM pg_catalog.pg_proc p, pg_catalog.pg_namespace n, pg_catalog.pg_type t WHERE p.pronamespace=n.oid AND p.prorettype=t.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'getallmacpoolrangesbymacpoolid' ORDER BY n.nspname, p.proname, p.oid::text < 2017-04-25 12:21:29.865 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:21:29.865 CEST >STATEMENT: select * from getallmacpoolrangesbymacpoolid() And for all the errors for today: < 2017-04-25 03:23:08.098 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" < 2017-04-25 12:13:03.519 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:21:29.827 CEST >ERROR: function gettagsbyparent_id() does not exist at character 16 < 2017-04-25 12:21:29.865 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 But the first one is old: grep fact_value_id_fk /data/pgsql/9.4/data/pg_log/postgresql-* /data/pgsql/9.4/data/pg_log/postgresql-Mon.log:< 2017-04-24 03:38:33.212 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Sat.log:< 2017-04-22 04:12:59.608 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Sun.log:< 2017-04-23 03:52:01.341 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Tue.log:< 2017-04-25 03:23:08.098 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" ovirt was working on monday morgning, I'm positive about that.
On Tue, Apr 25, 2017 at 1:28 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
I activated pg query log and got that:
grep gettagsbyparent_id /data/pgsql/9.4/data/pg_log/postgresql-Tue.log < 2017-04-25 12:21:29.770 CEST >LOG: execute <unnamed>: SELECT NULL AS PROCEDURE_CAT, n.nspname AS PROCEDURE_SCHEM, p.proname AS PROCEDURE_NAME, NULL, NULL, NULL, d.description AS REMARKS, 2 AS PROCEDURE_TYPE, p.proname || '_' || p.oid AS SPECIFIC_NAME FROM pg_catalog.pg_namespace n, pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_description d ON (p.oid=d.objoid) LEFT JOIN pg_catalog.pg_class c ON (d.classoid=c.oid AND c.relname='pg_proc') LEFT JOIN pg_catalog.pg_namespace pn ON (c.relnamespace=pn.oid AND pn.nspname='pg_catalog') WHERE p.pronamespace=n.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'gettagsbyparent_id' ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, p.oid::text
This query does not seem to be originated by oVirt, but by postgresql-jdbc [1]. Can you try downgrading that one as well, and then restart the engine? Thanks. [1] https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgr...
< 2017-04-25 12:21:29.787 CEST >LOG: execute <unnamed>: SELECT n.nspname,p.proname,p.prorettype,p.proargtypes, t.typtype,t.typrelid, p.proargnames, p.proargmodes, p.proallargtypes, p.oid FROM pg_catalog.pg_proc p, pg_catalog.pg_namespace n, pg_catalog.pg_type t WHERE p.pronamespace=n.oid AND p.prorettype=t.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'gettagsbyparent_id' ORDER BY n.nspname, p.proname, p.oid::text < 2017-04-25 12:21:29.827 CEST >ERROR: function gettagsbyparent_id() does not exist at character 16 < 2017-04-25 12:21:29.827 CEST >STATEMENT: select * from gettagsbyparent_id()
And:
grep getallmacpoolrangesbymacpoolid /data/pgsql/9.4/data/pg_log/postgresql-Tue.log < 2017-04-25 12:13:03.519 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:13:03.519 CEST >STATEMENT: select * from getallmacpoolrangesbymacpoolid(); < 2017-04-25 12:21:29.816 CEST >LOG: execute <unnamed>: SELECT NULL AS PROCEDURE_CAT, n.nspname AS PROCEDURE_SCHEM, p.proname AS PROCEDURE_NAME, NULL, NULL, NULL, d.description AS REMARKS, 2 AS PROCEDURE_TYPE, p.proname || '_' || p.oid AS SPECIFIC_NAME FROM pg_catalog.pg_namespace n, pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_description d ON (p.oid=d.objoid) LEFT JOIN pg_catalog.pg_class c ON (d.classoid=c.oid AND c.relname='pg_proc') LEFT JOIN pg_catalog.pg_namespace pn ON (c.relnamespace=pn.oid AND pn.nspname='pg_catalog') WHERE p.pronamespace=n.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'getallmacpoolrangesbymacpoolid' ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, p.oid::text < 2017-04-25 12:21:29.821 CEST >LOG: execute <unnamed>: SELECT n.nspname,p.proname,p.prorettype,p.proargtypes, t.typtype,t.typrelid, p.proargnames, p.proargmodes, p.proallargtypes, p.oid FROM pg_catalog.pg_proc p, pg_catalog.pg_namespace n, pg_catalog.pg_type t WHERE p.pronamespace=n.oid AND p.prorettype=t.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'getallmacpoolrangesbymacpoolid' ORDER BY n.nspname, p.proname, p.oid::text < 2017-04-25 12:21:29.865 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:21:29.865 CEST >STATEMENT: select * from getallmacpoolrangesbymacpoolid()
And for all the errors for today: < 2017-04-25 03:23:08.098 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" < 2017-04-25 12:13:03.519 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16 < 2017-04-25 12:21:29.827 CEST >ERROR: function gettagsbyparent_id() does not exist at character 16 < 2017-04-25 12:21:29.865 CEST >ERROR: function getallmacpoolrangesbymacpoolid() does not exist at character 16
But the first one is old: grep fact_value_id_fk /data/pgsql/9.4/data/pg_log/postgresql-* /data/pgsql/9.4/data/pg_log/postgresql-Mon.log:< 2017-04-24 03:38:33.212 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Sat.log:< 2017-04-22 04:12:59.608 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Sun.log:< 2017-04-23 03:52:01.341 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts" /data/pgsql/9.4/data/pg_log/postgresql-Tue.log:< 2017-04-25 03:23:08.098 CEST >ERROR: update or delete on table "fact_values" violates foreign key constraint "fact_value_id_fk" on table "facts"
ovirt was working on monday morgning, I'm positive about that.
-- Didi
Le 25 avr. 2017 à 13:28, Yedidyah Bar David <didi@redhat.com> a écrit :
On Tue, Apr 25, 2017 at 1:28 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
I activated pg query log and got that:
grep gettagsbyparent_id /data/pgsql/9.4/data/pg_log/postgresql-Tue.log < 2017-04-25 12:21:29.770 CEST >LOG: execute <unnamed>: SELECT NULL AS PROCEDURE_CAT, n.nspname AS PROCEDURE_SCHEM, p.proname AS PROCEDURE_NAME, NULL, NULL, NULL, d.description AS REMARKS, 2 AS PROCEDURE_TYPE, p.proname || '_' || p.oid AS SPECIFIC_NAME FROM pg_catalog.pg_namespace n, pg_catalog.pg_proc p LEFT JOIN pg_catalog.pg_description d ON (p.oid=d.objoid) LEFT JOIN pg_catalog.pg_class c ON (d.classoid=c.oid AND c.relname='pg_proc') LEFT JOIN pg_catalog.pg_namespace pn ON (c.relnamespace=pn.oid AND pn.nspname='pg_catalog') WHERE p.pronamespace=n.oid AND n.nspname LIKE 'public' AND p.proname LIKE 'gettagsbyparent_id' ORDER BY PROCEDURE_SCHEM, PROCEDURE_NAME, p.oid::text
This query does not seem to be originated by oVirt, but by postgresql-jdbc [1]. Can you try downgrading that one as well, and then restart the engine? Thanks.
[1] https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgr...
You nailed it ! There is two versionning approch in postgres: - For the database and library, the first two level are part of the version name, so you install postgresql-92 or postgresql-94 and yum update don't break it. - For the jdbc drivers, they do continuous upgrade: yum update postgresql-jdbc Loaded plugins: etckeeper, fastestmirror, versionlock Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package postgresql-jdbc.noarch 0:9.2.1002-5.el7 will be updated ---> Package postgresql-jdbc.noarch 0:42.0.0-1.rhel7 will be an update --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================================================================================================================================================================== Package Arch Version Repository Size ======================================================================================================================================================================================================================================================== Updating: postgresql-jdbc noarch 42.0.0-1.rhel7 pgdg94 508 k But I need pgdg94 install on my ovirt server, to have pg_dump/pg_restore matching the one from the server. For now I will prevent upgrade from yum configuration.
participants (2)
-
Fabrice Bacchella -
Yedidyah Bar David