On 21/09/16 08:50, Michael Paquier wrote:
> On Fri, Sep 16, 2016 at 6:54 PM, <marco.nenciarini@2ndquadrant.it> wrote:
>> The workaround I found to reset this state is to force the instance thro=
ugh
>> another backup recovery, by starting an exclusive backup, saving the
>> backup_label, stopping the backup and restarting the instance with the s=
aved
>> backup_label in place.
>=20
> That's not user-friendly.
>=20
I agree, it isn't. But it's the only way to reset that state with the
current available tools. Probably, the pg_resetxlog tool could be
modified to allow the user to reset that value only.
>> I don't know the best way to handle this situation, but at least, I'd li=
ke a
>> warning message when the instance exits from the crash recovery while
>> backupStartPoint is still set.
>=20
> So you would get such a warning even when you restore from a backup
> willingly, no? That may confuse users. Now, the case you are referring
> to is unfortunately a known problem with exclusive backups... There is
> no way to make the difference between a node restored from a backup
> and a node that crashed while a backup is taken.
> And that may be a
> reason to make non-exclusive backups more popular because they are
> more reliable.
You are right, an eventual solution to this issue must not interfere
with normal recovery from a backup.
To mitigate the effect we could to reset the state of the
backupStartPoint field during the pg_start_backup invocation. So, if a
backup will be interrupted by a reboot, the instance state will be
cleaned during the next backup.
Another possibility could be to emit a warning (and maybe reset
backupStartPoint value) during the shutdown of an instance that is fully
"in production".
Regards,
Marco
--=20
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it
