Re: [COMMITTERS] pgsql: New SQL functons pg_backup_in_progress() and pg_backup_start_tim - Mailing list pgsql-hackers

On Fri, Jun 15, 2012 at 8:49 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> I agree that pg_backup_in_progress() is confusing, if it returns false while
>> you're running pg_basebackup. In the doc changes you proposed, you call the
>> pg_start/stop_backup() a "low level API" for taking backups. That's not
>> suitable for a function name, but I think we should work on that, and find a
>> better term that works.
>>
>> Backup mode? Filesystem backup mode?
>
> We already have backup mode, and it covers both of them really. And
> filesystem backup mode is also what pg_basebackup does - it takes a
> filesystem backup...
>
> The easiest one I can think of is the "manual backup mode", but in the
> other thread Simon didn't like that term.

Let me make things a bit worse since people are trying to figure out
nomenclature and positioning in the documentation, especially taking
consideration of pg_basebackup:

I think that the "exclusive" nature of the pg_(start|stop)_backup mode
(to use the original terminology under reconsideration) is quite
harmful, related to what was raised in
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php (I
revisited this in
http://archives.postgresql.org/pgsql-hackers/2011-11/msg01696.php)

After mulling over this some more, I am less on the fence about how
unfortunate it is that Postgres cannot restart when doing an
"exclusive" base backup: I think it is a severe anti-feature that
should gradually be retired.  pg_basebackup has the better contract
(whereby some information is very carefully inserted into the backup
to trigger archive recovery), and pg_(start|stop)_backup has a worse
one. There are more people performing archiving than there are writing
archiving tools, and the latter category should just be expected to
carefully get this right as pg_basebackup does.  Tragically,
pg_basebackup's archiving technique does not meet my requirements (and
it's a non-trivial optimization that I'm not sure makes sense in every
case, so I'm not sure it should be added), so those of us with other
archivers are left with workarounds like moving the backup file around
during the backup process.

Such a move would render the notion of a "backup in progress" or
single "backup start time" more or less obsolete.  That's not to say
that more reporting in the meantime shouldn't be added, because
changing the archiving contract will take time, and meanwhile people
are going to have to use the old contract between the archiving
software of choice and Postgres for quite a while.  However, I think
the eventual deprecation of "exclusive" backup mode is where things
should go, and maybe this will change someone's perception of how this
should be represented in documentation.

Finally, this complexity goes away (or rather, is moved, but hopefully
made more cohesive) if one can delegate all WAL persistence to other
software.  The presence of backup_label most basically affects whether
one wishes to recover via restore_command or the pg_xlog directory,
which only mattered insomuch that the archiver was an asynchronous
form of replication and pg_xlog was nominally a synchronous one.  It's
becoming less clear to me that these are deserving of being so
distinct in the future: they're all sources of WAL, and with syncrep
and group-commit already available, we're might be in a position to
remove some surface area and duplicated concepts in tooling. Slowly.

-- 
fdr