spictera
spictera
Output from pgbackrest ``` 2022-03-21 15:44:56.136 P00 INFO: full backup size = 43.2MB, file total = 1864 2022-03-21 15:44:56.136 P00 INFO: backup command end: completed successfully (41456ms) 2022-03-21 15:44:56.136 P00...
Interesting solution to avoid truncated or partly written content. And I do agree that Posix has its limitations when it comes to signaling if a file is in good shape...
There are other ways to detect if there are truncated or partly written data. Just by collecting number of written data, plus return code from close will help If one...
Or storing the result codes for those who has not completed
for example ``` written = write(fd,data,size); if(written != size) { // error, or buffer full } ``` And when the data has been written in full, and the code sends...
That is why you get your result codes from the close, which is where the transaction has ended. transaction of a data copy starts with a create, or open, and...
or why are you using the "tmp" files? Isn't that to keep track of files that didn't end properly? I would say that one can do it by tracking the...
Take an application such as RMAN. They are not using "tmp" (atomic write), they write directly to the targeted file, and instead monitores the whole data copy process end-to-end.
Thanks for that; but that will unfortunately not resolve the issue as the targeted storage uses timestamp on seconds since epoch, not microseconds. That is why we encountered this issue,...
Do you need to rewrite the info file so many times? Can't the content be keept in memory until the backup process has ended?