Long time ago I wrote first version of explain.depesz.com. Since then I gradually improve it. But, what was lacking was a way to paste queries too – explain.depesz.com handles explains, but not plain queries.
Now this has changed. I created new site: paste.depesz.com which allows for sharing queries.
Thanks to pgFormatter it also does query pretty-printing (which is not something readily available on other paste sites).
Obviously, code to the site is publicly available in GitHub repo.
Now, goes my request – if you have designer skills, I would greatly appreciate someone that could make the site nicer (prettier, more responsive). My CSS/JS knowledge is pretty limited, and I'm happy anyway about what I did with the look right now, but if you could make it nicer/prettier, that would be amazing.
Have fun, and if you have any feature requests, please post them in here…
Otto Bretz reported bug in OmniPITR.
The bug was that when using -dr (remote destinations for backups) – you couldn't use –skip-xlogs. Obvious overlook on my side.
Fix was trivial, and so 1.3.2 version was born.
I just now committed new version of OmniPITR.
You can download it from:
The important change about 1.3.0 is that there is new tool – omnipitr-backup-cleanup. What is it for?
Continue reading OmniPITR 1.3.0
Title: OmniPITR v1.2.0 released
It's been a while since last release, but the new one finally arrived, and has some pretty cool goodies 🙂
Continue reading OmniPITR v1.2.0 released
Yesterday, I did release new version of OmniPITR – 1.1.0.
You can get it from github or from PgXN.
What's new? Couple of things:
Continue reading New OmniPITR release
One of the features that is actually disliked is anonymization. But, regardless of the dislike – it has some users. And one of the user mailed me with information about a bug – namely – foreign table file names were not anonymized.
So, I wrote a patch, tests, released new version of underlying parsing library.
Continue reading Changes on explain.depesz.com
Finally, after all these years, version 1.0.0 of OmniPITR got Released.
The reason I went to 1.0.0, and not 0.8.0 is very simple – finally, all programs in bin/ actually work 🙂
By that I mean: since beginning there was “omnipitr-monitor" – which simply didn't work, because work on it was always postponed. But now, it does. It's functionality is not all that great now, but it works, checks some basic data about replication, and can be used in production.
Now, there is still a todo but these things are less important.
I have to say that writing, and maintaining OmniPITR taught me a lot about PostgreSQL – how it works, and what really WAL is. It was really cool.
Just released new version of OmniPITR.
This version has one important new feature: when you're calling omnipitr-backup-slave, it will make backups only of required xlog files, and not, as previously, of all in walarchive directory.
This is important, especially in case you have multiple slaves, or you keep shared long-term walarchive. Previously – backups would get all files from walarchive (-s option to omnipitr-backup-slave), but now, it picks just the ones that are needed.
On somehow related note – I will be working now, finally, to get omnipitr-monitor functionality working.
Just released new version, 0.6.0 (it should be visible on pgxn soon) of OmniPITR set of tools.
New version has one new feature – parallelism.
This works in omnipitr-archive and omnipitr-backup-* programs, and allows for parallel delivery to remote destinations (multiple -dr switches).
Also – if you're using compresses wal archive and omnipitr-backup-slave reading from it – all the wal files have to be decompressed before making backup – and this decompression can be parallelized too.
All parallelization is controled using -PJ option (–parallel-jobs), so you can add “-PJ 10" to get up to 10 decompressions at the same time or up to 10 deliveries at the same time.
Just released version 0.3.0 of our tool for handling WAL based replication in PostgreSQL – OmniPITR.
Version jump is related to addition of another tool – omnipitr-synch. This tool is used to copy PostgreSQL data dir (including all tablespaces of course) to remote location(s).
While this process is usually simple (call pg_start_backup(), transfer data, call pg_stop_backup()), thanks to the tool it can be wrapped as single call, with standardized logging, and tested logic. It also makes it trivial, and cheap, to setup more than one new slave at a time, without need to read data off master more than once.