> 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 

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 

Users mailing list

Reply via email to