Does OmniPITR support PostgreSQL 10?
Closed this issue · 10 comments
There's no mention of it in the README.
Unfortunately no. There is currently no plan (at least on my side). Not sure how big of a work it would be, but if there would be enough interest I might work on it, though not sure when exactly.
Hey, i tried to see how much of work it would be to add support for 10, i'm still unsure of the ideal way doing it. I also did a search and replace s/pg_xlog/pg_wal/ and everything i tried afterwards seemed to work fine. Obviously, this is not the best way to do this. I think that omnipitr is still useful, even with replication slots (lots of logging, nice way to create self contained backups esp. from a slave) so honestly i don't wanna see it dying. For some cases (eg. backups) we communicate with the db so getting the version seems pretty easy, but archiving is unaware of the version and asking the db version does seem like the wrong way doing this.
Depesz, since omnipitr is your baby, when you get a chance can you take a look and suggest a good way adding support for 10 (maybe a configurable ?) i will be happy to work on this.
Well, we could:
- have new version specifically for pg 10 on (doing the pg_xlog/pg_wal) change
- have it configurable using command line switch
- make it discover version and appropriate directory name on its own
3rd is best, but the most complex
2nd seems to me to be bad idea
1st seems to be doable, and easy, and perhaps acceptable, since the project is in omniti-labs, I guess its up for you guys to decide.
I would assume that such a change is pretty big, so we could simply release OmniPITR v2. which (for now) simply uses pg_wal instead of pg_xlog.
@joar does that sound acceptable for your usecase?
@depesz To me (2) looks most appealing, since it could potentially be hard to fight the auto-detection of (3) if it decides wrongly.
If (2) was implemented with the s/xlog/wal/ as opt-in, it may even be possible to keep compatibility and avoid having to manage multiple codebases for PG {9,10}
As an outsider:
- (3) seems to be the most complex option, with the most room for bugs in unthought-of-environments. Imagine trying to figure out how to get (3) to change it's mind if it decides wrongly, maybe with a command line option :)
- (2) seems to be more complex than (1)
- (1) seems harder to maintain as a developer than (2) and harder for users maintaining both PG 9.x and PG 10 servers.
In other words, (2) is my second choice over (1), but I would be happy with any option as long as it is reliable.
Not sure how you think autodetection could get it wrong. Any kind of auto-detection that I can think of is either by calling show server_version_num or by readign PG_VERSION file.
On the other hand - giving user another option to care about it bound to shoot the user in the foot sooner or later.
As such - I'm very, very negatively thinking about --wal-directory-name=... option, and I'm only, realistically, considering either new version of omnipitr for Pg10+, or having it autodetect and use appropriate directory name.
As of now, given the time I have, I'm much more inclined to make OmniPITR v2, which works with Pg10+, and that's it.
I did commit, just now, to branch OmniPITRv2 with code that should make OmniPITR work properly with Pg10. Any chance you could run it through some tests, @joar or @vventirozos ?
i can definitely run tests, did you also change pg_log -> log ?
i searched for clog, but omnipitr doesn't reference it anywhere so we should be good therre.
nvm, i saw you didn't and i made the change
I have tested branch OmniPITRv2 (all scripts) and everything works fine.
Just merged v2 to master, tagged and released v2.