On Wed, Feb 19, 2020 at 12:37:00PM -0600, David Steele wrote:
> On 2/19/20 2:13 AM, Michael Paquier wrote:
>> Please note that pg_internal.init is listed within noChecksumFiles in
>> basebackup.c, so we would miss any temporary pg_internal.init.PID if
>> we don't check after the file prefix and the base backup would issue
>> extra WARNING messages, potentially masking messages that could
>> matter. So let's fix that as well.
>
> Agreed. Though, I think pg_internal.init.XX should be excluded from the
> backup as well.
Sure. That's the intention. pg_rewind, pg_checksums and basebackup.c
are all the things on my list.
> As far as I can see, the pg_internal.init.XX will not be cleaned up by
> PostgreSQL on startup. I've only tested this in 9.6 so far, but I don't see
> any differences in the code since then that would lead to better behavior.
> Perhaps that's also something we should fix?
Not sure that it is worth spending cycles on that at the beginning of
recovery as when a mapping file is written its temporary entry
truncates any existing one present matching its name.
> I'm really not a fan of a blind prefix match. I think we should stick with
> only excluding files that are created by Postgres.
Thinking more on that, excluding any backup_label with a custom suffix
worries me as it could cause a potential breakage for exiting backup
solutions. So attached is an updated patch making things in a
smarter way: I have added to the exclusion lists the possibility to
match an entry based on its prefix, or not, the choice being optional.
This solves the problem with pg_internal.PID and is careful to not
exclude unnecessary entries like suffixed backup labels or such. This
leads to some extra duplication within pg_rewind, basebackup.c and
pg_checksums but I think we can live with that, and that makes
back-patching simpler. Refactoring is still tricky though as it
relates to the use of paths across the backend and the frontend..
> So backup_label.old and
> tablespace_map.old should just be added to the exclude list. That's how we
> have it in pgBackRest.
That would be a behavior change. We could change that on HEAD, but I
don't think that this can be back-patched as this does not cause an
actual problem.
For now, my proposal is to fix the prefix first, and then let's look
at the business with tablespaces where needed.
--
Michael