Greetings, * Paul Förster (paul.foerster@xxxxxxxxx) wrote: > > On 29. Jun, 2020, at 15:32, Stephen Frost <sfrost@xxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
