> Le 23 avr. 2017 à 10:56, Yedidyah Bar David <d...@redhat.com> a écrit :
>
> On Sun, Apr 23, 2017 at 10:59 AM, Fabrice Bacchella
> <fabrice.bacche...@orange.fr> wrote:
>>
>>> Le 23 avr. 2017 à 07:59, Yedidyah Bar David <d...@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.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
