From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file) |
Date: | 2022-10-05 05:16:17 |
Message-ID: | Yz0TIWtZcpWDKCFl@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-10-05 05:29:56 | Re: JUMBLE_SIZE macro in two files |
Previous Message | Peter Geoghegan | 2022-10-05 04:00:46 | Re: New strategies for freezing, advancing relfrozenxid early |