xmloption=DOCUMENT"/.
Do you think of any other way to solve this issue ?
What if we got the 2 xml options used in the database?
Would it be possible to have something like : ALTER TABLE ... ALTER
COLUMN ... SET XML OPTION ...; ?
Kind regards,
--
Stefan FERCOT
http://dalibo.com - http:
cremental backups,
they could detect potential issues sooner.
Ultimately, users will still need their full backups and WAL archives.
If pg_combinebackup fails for any reason, the fix will be to perform the
recovery from the full backup directly.
They still should be able to recover, just slower.
--
Stefan FERCOT
Data Egret (https://dataegret.com)
l tests only seem to cover the
archives generation but not actually trying to recover using it. I wasn't sure
it was interesting to add such tests right now, so I didn't considered it for
this patch.
Many thanks in advance for your feedback and thoughts about this,
Kind Regards,
--
Stefan FERCO
use-cases
too (i.e. like avoiding to store empty files, or storing the checksums state of
the cluster).
Kind Regards,
--
Stefan FERCOT
Data Egret (https://dataegret.com)
n open item, for me and Robert.
Thanks for this! It's probably not up to core docs to state all the steps that
would be needed to develop a complete backup solution but documenting the links
between the tools and mostly all the caveats (the "don't use INCREMENTAL.*
filenames&q
es sense to improve the in
core backup capabilities, the more we go in that direction, the more we'll rely
on outside orchestration.
So IMHO it also worth worrying about given more leverage to such orchestration
tools. In that sense, I really like the idea to extend the backup functions.
More thought
use it on the field and possibly give some feedback.
As you mentioned in [1], we're not going to start rewriting the implementation
a week after feature freeze nor probably already start building big new things
now anyway.
So maybe let's start with documenting the possible gotchas/corner c
