Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)

On Tue, Oct 04, 2022 at 06:24:18PM +0530, Bharath Rupireddy wrote:
> I'm fine with doing either of these things. Let's hear from others.
>
> I've added a CF entry - https://commitfest.postgresql.org/40/3927/

About 0002, I am not sure that it is worth bothering. Sure, this
wastes a few bytes, but I recall that there are quite a few places in
the code where we imply a WAL segment but append a full path to it,
and this creates a few bumps with back-patches.

--- a/src/bin/pg_upgrade/pg_upgrade.h
+++ b/src/bin/pg_upgrade/pg_upgrade.h
@@ -10,6 +10,7 @@
#include <sys/stat.h>
#include <sys/time.h>

+#include "access/xlog_internal.h"
#include "common/relpath.h"
#include "libpq-fe.h"
Well, xlog_internal.h includes a few backend-only definitions. I'd
rather have us untangle more the backend/frontend dependencies before
adding more includes of this type, even if I agree that nextxlogfile
would be better with the implied name size limit.

Saying that, 0001 is a nice catch, so applied it. I have switched the
two TLI variables to use TimeLineID, while touching the area.
--
Michael