Bugzilla

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> >  If the source database is modified by an external process or via a database connection other than the one being used by the backup operation

I see, I had glympsed over the "database connection other than". Then we likely don't want to use a different handle because we'd just restart too often.
At this point we should better evaluate if there may concerns with using the handle on a third thread, there may be some special handling to do on shutdown. Or eval whether the cost of doing it in the helper thread is acceptable.

> It looks to me like the passed in filename is created write away, as soon as the backup is initiated. It looks like .wal files are also created. If a backup is halfway done or aborted, the files remain and I think it's the responsibility of the caller of the API to clean them up.

Then how does a consumer know if that backup is complete or not, supposing the caller crashes in the middle of the backup?

Another concern that I was just thinking about is privacy, if we're just making copies of profile database somewhere else in the system, then when I'm removing data from my profile, those copies will still have it until a new backup is started. Though recognizing which operations should or should not discard them may not be trivial.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> >  If the source database is modified by an external process or via a database connection other than the one being used by the backup operation

I see, I had glympsed over the "database connection other than". Then we likely don't want to use a different handle because we'd just restart too often.
At this point we should better evaluate if there may concerns with using the handle on a third thread, there may be some special handling to do on shutdown (hold shutdown mutex and ensure we don't continue the backup after closing the connection). Or eval whether the cost of doing it in the helper thread is acceptable.

> It looks to me like the passed in filename is created write away, as soon as the backup is initiated. It looks like .wal files are also created. If a backup is halfway done or aborted, the files remain and I think it's the responsibility of the caller of the API to clean them up.

Then how does a consumer know if that backup is complete or not, supposing the caller crashes in the middle of the backup?

Another concern that I was just thinking about is privacy, if we're just making copies of profile database somewhere else in the system, then when I'm removing data from my profile, those copies will still have it until a new backup is started. Though recognizing which operations should or should not discard them may not be trivial.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> >  If the source database is modified by an external process or via a database connection other than the one being used by the backup operation

I see, I had glympsed over the "database connection other than". Then we likely don't want to use a different handle because we'd just restart too often.
At this point we should better evaluate if there may concerns with using the handle on a third thread, there may be some special handling to do on shutdown (hold shutdown mutex and ensure we don't continue the backup after closing the connection). Or eval whether the cost of doing it in the helper thread is acceptable.

> It looks to me like the passed in filename is created write away, as soon as the backup is initiated. It looks like .wal files are also created. If a backup is halfway done or aborted, the files remain and I think it's the responsibility of the caller of the API to clean them up.

Then how does a consumer know if that backup is complete or not, supposing the caller crashes in the middle of the backup? it may be worth using a custom file extension (like for downloads) and rename once backup is complete.

Another concern that I was just thinking about is privacy, if we're just making copies of profile database somewhere else in the system, then when I'm removing data from my profile, those copies will still have it until a new backup is started. Though recognizing which operations should or should not discard them may not be trivial.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #5)
> >  If the source database is modified by an external process or via a database connection other than the one being used by the backup operation

I see, I had visually skipped the "database connection other than" part. Then we likely don't want to use a different handle because we'd just restart too often.
At this point we should better evaluate if there may concerns with using the handle on a third thread, there may be some special handling to do on shutdown (hold shutdown mutex and ensure we don't continue the backup after closing the connection). Or eval whether the cost of doing it in the helper thread is acceptable.

> It looks to me like the passed in filename is created write away, as soon as the backup is initiated. It looks like .wal files are also created. If a backup is halfway done or aborted, the files remain and I think it's the responsibility of the caller of the API to clean them up.

Then how does a consumer know if that backup is complete or not, supposing the caller crashes in the middle of the backup? it may be worth using a custom file extension (like for downloads) and rename once backup is complete.

Another concern that I was just thinking about is privacy, if we're just making copies of profile database somewhere else in the system, then when I'm removing data from my profile, those copies will still have it until a new backup is started. Though recognizing which operations should or should not discard them may not be trivial.