Re: detecting binary backup in progress

On 31 May 2013 21:06, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-05-31 22:53:14 +0300, Heikki Linnakangas wrote:
>> On 31.05.2013 22:36, Andres Freund wrote:
>> >On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
>> >>Note that pg_is_in_backup() just checks for presence of
>> >>$PGDATA/backup_label. Also note that pg_basebackup doesn't create
>> >>backup_label in the server. It's included in the backup that's sent to the
>> >>client, but it's never written to disk in the server. So checking for
>> >>backup_label manually or with pg_is_in_backup() will return false even if
>> >>pg_basebackup is running.
>> >
>> >Whoa. You are right, but I'd call that a bug. I don't understand why we
>> >aren't just checking
>> >XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?
>>
>> Well, depends on what you imagine the function is used for. If you think of
>> it as "will pg_start_backup() throw an error if I call it now", or "do I
>> need to call pg_stop_backup()", then the current behavior is correct.
>>
>> The manual says:
>> >pg_is_in_backup() bool True if an on-line exclusive backup is still in progress.
>>
>> So clearly that is intentional.
>
> Well, just because it's intentional, doesn't mean its a good idea
> ;). There very well are reasons to check for in progress non-exclusive
> backups as well. You e.g. wouldn't want to restart the database while
> the weekly base backup of your 1TB database is in progress, just because
> it's done via the replication protocol.
>
> If we weren't in beta 1 already I'd vote for making it into:
> pg_backup_in_progress(OUT bool exclusive, OUT int non_exclusive) or
> similar. Perhaps we should do that anyway?
>
>> That could use some rephrasing, though; a layman won't know what an
>> "exclusive backup" is.
>
> True. Although I have to admit I can't come up with a succinct name for
> it it right now.

I see that this exact discussion has happened once before, after the
initial commit.

AFAICS nobody likes the fact that pg_is_in_backup() only covers
exclusive backups. The problem seems to be that we can't find a better
term.

But the problem remains that having a function called
pg_is_in_backup() that *clearly* does *not* do what it says, is a
problem. Yes, few people will understand what an exclusive backup is,
but that is a very good reason to not split hairs in the definition.

The way to resolve this is to have two functions:

pg_is_in_backup() - which covers both/all kinds of backup
pg_is_in_exclusive_backup() - which covers just the exclusive backup mode

and some clear documentation that explains why the two functions are necessary.

Any objections to me committing those changes?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services