2 ms·
"Point in time restore" is a bad way to call the feature if you don't let your customers pick a moment in time to restore to, so those tricks ensure that there'
by solatic 2y ago
"Point in time restore" is a bad way to call the feature if you don't let your customers pick a moment in time to restore to, so those tricks ensure that there's enough WAL entries to allow people to pick with per-second granularity.
- pintxo 2y agoOne can let users pick a time and then just replay the closest backup? Why create empty backups?
- Doxin 2y agoBut if there has been no activity you surely can just pick the most recent log that's older than the time the user picked?
- Tostino 2y agoHow do you know the WAL was not lost during transmission, or the server crashed before transferring the WAL even though there were writes after the last WAL you have in your backup? That's why.
- bjornsing 2y ago> those tricks ensure that there's enough WAL entries to allow people to pick with per-second granularity How can they ensure that? Sounds more like they ensure that people can pick point in time with minute granularity. I’m no expert, but doesn’t postgres write a timestamp with each record in the WAL? I know that when you start postgres in recovery mode it lets you specify a timestamp you want to restore to, and I don’t think that timestamp needs to be on a WAL file boundary. (So the tricks seem weird / unnecessary to me.)