Greetings, * Paul Förster (paul.foers...@gmail.com) wrote: > > On 29. Jun, 2020, at 15:32, Stephen Frost <sfr...@snowman.net> wrote: > > > > Presumably they mean 'quiesce', except that that *isn't* what PG's > > yes, sorry, "quiece" was a typo on my part. I never fully understood what > they mean with "quiesce" anyway. But then, I'm not the storage specialist in > out company anyway.
On some database platforms it basically means "stop writing", in order to allow a backup to be taken, but that's not what happens on PG and any documentation about using PG's start/stop definitely shouldn't be talking about quiescing the database. > > start/stop backup calls do, and assuming that's what happens is quite > > wrong and could lead to issues. > > > > The PG start/stop backup calls do things like wait for a checkpoint to > > happen and track when that checkpoint was and return that info along > > with whatever the stopping point of the backup is- so that you can make > > sure that you have all of the WAL between those two points, and so you > > can create the backup_label file that's needed to indicate on restore > > that you're restoring from a backup and not just doing crash recovery. > > > > If it isn't an atomic snapshot across everything then start/stop calls > > have to be done as well as all that other fun stuff. > > that's exactly why I want control over pg_start_backup() and > pg_stop_backup(). It may be in the form of pre- and post-scripts, but I want > control over it. I just can't seem to build trust in a plugin that saw the > last release two years ago and which I can't even find out if it would allow > PITRs, works with the new API and such things. I certainly don't blame you, particularly given all the changes regarding how restore is done which went into v12- obviously anything that hasn't been updated since before v12 was released isn't going to work with those changes. Thanks, Stephen
signature.asc
Description: PGP signature
