Re: EXTERNAL: Re: Netapp SnapCenter - Mailing list pgsql-general

From Paul Förster
Subject Re: EXTERNAL: Re: Netapp SnapCenter
Date
Msg-id 842CC003-5A6D-4057-8560-59504807B9C7@gmail.com
Whole thread Raw
In response to Re: EXTERNAL: Re: Netapp SnapCenter  (Stephen Frost <sfrost@snowman.net>)
List pgsql-general
Hi Stephen,

> On 29. Jun, 2020, at 15:32, Stephen Frost <sfrost@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'mnot the storage specialist in out company anyway. 

> 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
yearsago and which I can't even find out if it would allow PITRs, works with the new API and such things. 

I may be wrong here, but my gut feeling about this is just not good for some reason.

Cheers,
Paul


pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: libpq pipelineing
Next
From: Bill Glennon
Date:
Subject: PostgreSQL database segsize