Re: Documentation Update: Document pg_start_backup checkpoint behavior

Bruce Momjian wrote:
> Michael Renner wrote:
>> +     processing.  Unfortunately it's currently not possible to expedite
>> +     the checkpointing done by pg_start_backup.
>>      </para>
>>     </listitem>
>>     <listitem>
> 
> I have combined the above patch with another change that reports a
> checkpoint is taking place:
> 
>     test=> select pg_start_backup('12');
>     NOTICE:  performing checkpoint
>      pg_start_backup
>     -----------------
>      0/2000020
>     (1 row)

Rather than deplore that you can't expedite the checkpoint, why don't we 
just make it possible? It's trivial to do, and in hindsight I think we 
should've implemented that option when we got smoothed checkpoints. 
Let's just decide what the command should look like.

The first question is what the default behavior should be? We've seen 
enough complaints and I've been bitten by that myself during development 
of other stuff often enough that I think we should change the default to 
immediate. From backwards-compatibility point of view, we shouldn't 
change the default, but then again an immediate checkpoint was what you 
got before 8.3.

For the interface, I can see two options:

1. New function

pg_start_backup('label') -> immediate checkpoint
pg_start_backup_lazy('label') -> lazy checkpoint

2. New argument

pg_start_backup('label') -> immediate checkpoint
pg_start_backup('label', false) -> immediate checkpoint
pg_start_backup('label', true) -> lazy checkpoint

The first looks nicer, IMHO, because the word 'lazy' makes it 
self-documenting. In the second form, you have to look at the manual to 
figure out what the 2nd argument does.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com