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
