6:40 a.m.
Le 23 avr. 2017 à 10:56, Yedidyah Bar David <didi(a)redhat.com> a
écrit :
On Sun, Apr 23, 2017 at 10:59 AM, Fabrice Bacchella
<fabrice.bacchella(a)orange.fr> wrote:
>
>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David <didi(a)redhat.com> a écrit :
>>>>
>
>>>>
>>>> And it was not in the release notes, it's not funny to get this
warning
>>>> after starting the upgrade
>>
>> This isn't a new test, see above bug.
>>
>> Are you sure it's the first time you see it? Perhaps you upgraded your pg
>> server only after the last upgrade of the engine?
>>
>
> That's might true about the test, but not the autovacuum_vacuum_scale_factor and
others.
>
> And any way, about the test, having a different version of pg library and pg server
is quite common when you have a centralized pg. You might plan an upgrade any time and
don't expect every client to complain about a minor release, that's quite
unexpected.
Very well, so I detailed above a suggestion about what you can do.
Either make backup (and therefore rollback) optional, or make the test
more delicate. Neither seems trivial to me in terms of risk (although
they might be quite simple in the amount of code to change).
>
> The bug https://bugzilla.redhat.com/show_bug.cgi?id=1331168 is about major version, I
got complain from ovirt about patch level. That's not the same thing.
I didn't check PG's official terminology. The bug was about 9.2
against 9.5. In general, "9" is the major version, and the bug still
applied. It might be that they consider "9.2" to be the major version,
and "9.5" a different major version.
From the very bug description:
I'm testing migration from 3.6 EL6 with remote DBs (PG 8.x) to
4.0 EL7 while still using remote DBs (which I restored from backup).
Problem is 4.0 supports PG 9.x but I was still original PG 8.x.
engine-setup from 4.0 should know it needs PG 9.x and should check PG version even for
remote DBs.
In the extract from the man page, the main problems are also about major versions.
You test 9.2 against 9.5.
What I have failling is 9.4.8 against 9.4.11. That is very different from all the case
described.
> And the solution that ovirt propose is to have the server lying about version to all
of it's client.
Where did you see this?
Please set:
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.075
autovacuum_max_workers = 6
server_version = 9.4.8
Are in the log from the upgrade command.
The text you copied is: "Please use a Postgresql server of version
'9.4.8'"
> What can I do if every client I use require such a thing ?
You mean:
1. I want a single server with some version X
2. I want different clients with different versions X1, X2, ...
3. More than one of these clients requires the server to be the same
version as the client
?
I'd say - upgrade all such clients to the version of the server, or
make these clients not require that :-)
Yes make these clients not require that. Ovirt is one of those complaining client.