3:14 a.m.
Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi(a)redhat.com> a
écrit :
On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella
<fabrice.bacchella(a)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.
3:27 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
On Tue, Apr 25, 2017 at 11:14 AM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
> Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi(a)redhat.com> a écrit :
>
> On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella
> <fabrice.bacchella(a)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
4:10 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi(a)redhat.com> a
écrit :
On Tue, Apr 25, 2017 at 11:14 AM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
>
>> Le 25 avr. 2017 à 07:59, Yedidyah Bar David <didi(a)redhat.com> a écrit :
>>
>> On Mon, Apr 24, 2017 at 5:59 PM, Fabrice Bacchella
>> <fabrice.bacchella(a)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
4:14 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi(a)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.
5:05 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
> Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi(a)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
5:14 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
Le 25 avr. 2017 à 12:05, Yedidyah Bar David <didi(a)redhat.com> a
écrit :
On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
>
>> Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi(a)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.
5:21 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
On Tue, Apr 25, 2017 at 1:14 PM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
> Le 25 avr. 2017 à 12:05, Yedidyah Bar David <didi(a)redhat.com> a écrit :
>
> On Tue, Apr 25, 2017 at 12:14 PM, Fabrice Bacchella
> <fabrice.bacchella(a)orange.fr> wrote:
>>
>>> Le 25 avr. 2017 à 10:27, Yedidyah Bar David <didi(a)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
5:28 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
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.
6:28 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
On Tue, Apr 25, 2017 at 1:28 PM, Fabrice Bacchella
<fabrice.bacchella(a)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/pos...
< 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
7:48 a.m.
New subject: after upgrade from 4.0.4 to 4.1.1, no more gettagsbyparent_id
Le 25 avr. 2017 à 13:28, Yedidyah Bar David <didi(a)redhat.com> a
écrit :
On Tue, Apr 25, 2017 at 1:28 PM, Fabrice Bacchella
<fabrice.bacchella(a)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/pos...
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.
2558
days inactive
2558
days old
9 comments
2 participants
participants (2)
-
Fabrice Bacchella -
Yedidyah Bar David