Simon Riggs wrote:
>> If somebody stops the postmaster while an online backup is
>> in progress, there is no warning or nothing. Only the server
>> will fail to restart.
>
> Well, it seems best not to do this. There is always a need
> for a careful
> procedure to manually shutdown a live server, interlocking with other
> applications. ISTM like a manual procedure will resolve this for you.
You're arguing that there *should* be a manual intervention
if a server was shutdown while a backup was active.
> If we remove the file in the place you suggest then an Archive Recovery
> will succeed when it should fail, with no possibility of a hint, which
> seems a worse error.
>
>> How about my second suggestion:
>>
>> Remove backup_label when the server shuts down cleanly.
>> In that case an online backup in progress will not be useful
>> anyway, and there is no need to recover on server restart.
>
> That will make PITRs fail:
>
> 1. pg_start_backup()
> 2. backup
> 3. shutdown, removes backup_label
> 4. pg_stop_backup()
>
> step 4 will now fail because of a missing backup_label file.
Using the same kind of argument as you did above I would
say that pg_stop_backup() *should* fail if the server
restarted (and recovered!) inbetween - there was certainly something
fishy going on during the online backup.
In your list, you left out step 3.5: restart the server.
This step may fail if you do *not* remove the backup_label.
What is worse:
- Have pg_stop_backup() fail if the server was shut down
during the backup
or
- Prevent the server from restarting at all without manual
intervention.
I would say the latter.
Yours,
Laurenz Albe
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
