On Sun, Apr 23, 2017 at 2:53 PM, Fabrice Bacchella <fabrice.bacchella@orange.fr> wrote:
Le 23 avr. 2017 à 07:59, Yedidyah Bar David <didi@redhat.com> a écrit :
The main reason we require this is for pg_dump/pg_restore which are ran during setup/rollback (if needed). pg_dump can't know for sure that all the changes in the db were done using a client of its own version (that is, current machine usually), and if indeed a newer client was used, it might have used features that pg_dump of the lower version doesn't know how to back up (and especially pg_restore does not know how to restore). See also [1]. I seem to have tested there (can't remember anymore, see comment 13) 9.2 client with 9.5 server and it didn't work. pg_dump(1) manpage says:
Because pg_dump is used to transfer data to newer versions of PostgreSQL, the output of pg_dump can be expected to load into PostgreSQL server versions newer than pg_dump's version. pg_dump can also dump from PostgreSQL servers older than its own version. (Currently, servers back to version 7.0 are supported.) However, pg_dump cannot dump from PostgreSQL servers newer than its own major version; it will refuse to even try, rather than risk making an invalid dump. Also, it is not guaranteed that pg_dump's output can be loaded into a server of an older major version — not even if the dump was taken from a server of that version. Loading a dump file into an older server may require manual editing of the dump file to remove syntax not understood by the older server. Use of the --quote-all-identifiers option is recommended in cross-version cases, as it can prevent problems arising from varying reserved-word lists in different PostgreSQL versions.
I don't get it, but I don't know pg so I might be wrong.
You have a client application (like ovirt) written using features from V1 of pg.
Right.
It's running on a server where version V2 is installing. For good reasons, V2 >= V1 is needed.
Indeed.
The server is running a version V3. Again V3 >= V1 is needed. Except for major version, does V3 => V2 is really needed ?
For oVirt itself, no.
And for backup the problem is the same. It must probably know every features used in the application (so again being V1 or more). Why does it needs to match both V2 and V3 ? It will probably fits V2 is installation is the same. But that not mandatory. In a java application, the client library might be a jar provided by the application and pg_dump a tool installed with native os packaging. But how can complain against V3 ?
pg_dump is indeed a tool installed from the OS. I copied above the relevant part of its manpage - if you think it does a wrong thing, perhaps better continue the discussion on postgresql lists. For our concern, the only relevant fact is that we decided to backup the db using pg_dump during setup, and to restore it on rollback. If you want to make this backup optional, please open an RFE, as already requested, and we can discuss this there.
But with ovirt we have V1=V2=V3,
Not exactly. Using your terminology, we have V1<=V2, V2=V3.
even for for patch level (9.4.8 against 9.4.11). What kind of feature that ovirt don't know about might be missing ? I don't think ovirt might know about any 9.4 since you talked about version 9.2 as the official supported version.
At the time, oVirt didn't check versions at all, and so failed on a certain combination, and it was decided to require V2=V3, as a simple and effective solution. This was also specifically discussed there, as you can see for yourself, open to the public for review/comments. Check especially comments 9 to 19 (in bz 1331168). If you think we need a more delicate test, please open an RFE, preferably providing the details I suggested that should be considered for one. Also please recall that you have a third, very simple, IMHO, option. If for any reason you decided to have your server with version V3, simply install V3 on your client machine (the oVirt engine). This will be simple and solve all problems. If your concern is that the OS does not supply pg V3, then it applies also to the OS of the server. If that is a different OS, you are welcome to port oVirt engine to that OS so you can have all you want at once. You also have a fourth option - patch oVirt to not check for the version, by reverting the patch that introduced this check (might require a bit more work than "git revert", but not much): https://gerrit.ovirt.org/59941 Of course, this will essentially be a fork, and I'd personally not recommend it. But it's still an option. Best, -- Didi