On 12/21/23 07:37, Andres Freund wrote:
>
> On 2023-12-20 13:11:37 -0400, David Steele wrote:
>> I've run this through a bunch of scenarios (in my head) with parallel
>> backups and it does seem to hold up.
>>
>> I think we'd need to write the state file before XLOG_BACKUP_START just in
>> case. Seems better to have an extra state file rather than have one be
>> missing.
>
> That'd very significantly weaken the approach, afaict, because "external" base
> base backup could end up copying those files. The whole point is to detect
> broken procedures, so relying on such files being excluded from the base
> backup seems like a bad idea.
>
> I also see no need to do so - because we'd only verify that a backup start has
> been replayed when replaying XLOG_BACKUP_STOP there's no danger in not
> creating the files during XLOG_BACKUP_START, but doing so just before logging
> the XLOG_BACKUP_STOP.
Ugh, I meant XLOG_BACKUP_STOP. So sounds like we are on the same page.
>> Probably we'd want to exclude *all* state files from backups, though.
>
> I don't think so - I think we want the opposite? As noted above, I think in a
> safety net like this we shouldn't assume that backup procedures were followed
> correctly.
Fair enough.
>> Seems like in various PITR scenarios it could be hard to determine when to
>> remove them.
>
> Why? I think we can basically remove the files when:
>
> a) after the checkpoint during which XLOG_BACKUP_STOP was replayed - I think
> we already have the infrastructure to queue file deletions that we can hook
> into
> b) when replaying a shutdown checkpoint / after creation of a shutdown
> checkpoint
I thought about this some more. I *think* any state files a backup can
see would have to be for XLOG_BACKUP_STOP records generated during the
backup and they would get removed before the cluster had recovered to
consistency.
I'd still prefer to exclude state files from the backup, but I agree
there is no actual need to do so.
Regards,
-David