I think it would all make more sense if we described the use of
archive_command = something as being in "WAL Archive Mode". That would
then allow us to say:
"You can only take Online Backups while in WAL Archive Mode".
"If you ever wish to perform PITR, you must use WAL Archive Mode".
"If you backed-up in WAL Archive Mode, you can perform an Archive
Recovery".
It seems to me there are two different context in which one would be
making statements like this. And what we are "allowed to say"
depends greatly on context. These contexts are as follows:
1) Explaining the feature set of postgres to a potential user.
2) Explaining to an actual postgres user how to actually do something.
In the first case it makes the most sense to me to use industry
standard or very intuitive terminology to the extend that it exists.
ie (Transaction Logs vs. WAL). Incremental Backup and Point in Time
Recovery seem to be fairly commonly used and understood database
buzzwords for someone to investigate the feature set of an RDBMS.
In the second case it seems to me that the most important thing is
that you pick terminology that is consistent, unambiguous and clearly
defined. Log archival, PITR, etc are not point and click operations
like they are in say MS SQL Server. This gives us more flexibility
but it also requires a deeper understanding. If someone is unwilling
or unable to to learn whatever terminology you happen to come up with
then it seems to me they shouldn't even be attempting to set up one
of those features. At the same time if the terminology you uses
changes all the time (is not consistent), or if you can't figure out
what any of the terms mean (they are not clearly defined) or if you
use terms like "online backup" to mean both types of backup but then
use it once in a specific circumstance where only one usage is
appropriate (you are using the terms ambiguously) then users will be
confused and it will be your fault not theirs.
Just my 2 cents
Rick Gigger
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
