Re: Refactor backup related code (was: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Refactor backup related code (was: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?)
Date
Msg-id Yx7i7RyIJWfLdUT4@paquier.xyz
Whole thread Raw
In response to Re: Refactor backup related code (was: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Refactor backup related code (was: Is it correct to say, "invalid data in file \"%s\"", BACKUP_LABEL_FILE in do_pg_backup_stop?)
List pgsql-hackers
On Thu, Aug 11, 2022 at 09:55:13AM +0530, Bharath Rupireddy wrote:
> Here's the v2 patch, no change from v1, just rebased because of commit
> a8c012869763c711abc9085f54b2a100b60a85fa (Move basebackup code to new
> directory src/backend/backup).

I was skimming at this patch, and indeed it is a bit crazy to write
the generate the contents of the backup_label file at backup start,
just to parse them again at backup stop with these extra sscan calls.

-#define PG_STOP_BACKUP_V2_COLS 3
+#define PG_BACKUP_STOP_V2_COLS 3
It seems to me that such changes, while they make sense with the new
naming of the backup start/stop functions are unrelated to what you
are trying to solve primarily here.  This justifies a separate
cleanup, but I am perhaps overly-pedantic here :)
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_upgrade generated files in subdir follow-up
Next
From: John Naylor
Date:
Subject: Re: build remaining Flex files standalone