aboutsummaryrefslogtreecommitdiff
path: root/src/include/common/relpath.h
diff options
context:
space:
mode:
authorAndres Freund <andres@anarazel.de>2025-02-25 09:02:07 -0500
committerAndres Freund <andres@anarazel.de>2025-02-25 09:02:07 -0500
commit37c87e63f9e1a2d76db54fedcdf91d3895d200a6 (patch)
tree1289dd23f92391ef9ec5171b59f4ac76f2e14a02 /src/include/common/relpath.h
parent32c393f9f1f148febcd741e7067e9537825587cc (diff)
downloadpostgresql-37c87e63f9e1a2d76db54fedcdf91d3895d200a6.tar.gz
postgresql-37c87e63f9e1a2d76db54fedcdf91d3895d200a6.zip
Change relpath() et al to return path by value
For AIO, and also some other recent patches, we need the ability to call relpath() in a critical section. Until now that was not feasible, as it allocated memory. The fact that relpath() allocated memory also made it awkward to use in log messages because we had to take care to free the memory afterwards. Which we e.g. didn't do for when zeroing out an invalid buffer. We discussed other solutions, e.g. filling a pre-allocated buffer that's passed to relpath(), but they all came with plenty downsides or were larger projects. The easiest fix seems to be to make relpath() return the path by value. To be able to return the path by value we need to determine the maximum length of a relation path. This patch adds a long #define that computes the exact maximum, which is verified to be correct in a regression test. As this change the signature of relpath(), extensions using it will need to adapt their code. We discussed leaving a backward-compat shim in place, but decided it's not worth it given the use of relpath() doesn't seem widespread. Discussion: https://postgr.es/m/xeri5mla4b5syjd5a25nok5iez2kr3bm26j2qn4u7okzof2bmf@kwdh2vf7npra
Diffstat (limited to 'src/include/common/relpath.h')
-rw-r--r--src/include/common/relpath.h52
1 files changed, 50 insertions, 2 deletions
diff --git a/src/include/common/relpath.h b/src/include/common/relpath.h
index 5162362e7d8..6f2fce216f8 100644
--- a/src/include/common/relpath.h
+++ b/src/include/common/relpath.h
@@ -77,13 +77,61 @@ extern PGDLLIMPORT const char *const forkNames[];
extern ForkNumber forkname_to_number(const char *forkName);
extern int forkname_chars(const char *str, ForkNumber *fork);
+
+/*
+ * Unfortunately, there's no easy way to derive PROCNUMBER_CHARS from
+ * MAX_BACKENDS. MAX_BACKENDS is 2^18-1. Crosschecked in test_relpath().
+ */
+#define PROCNUMBER_CHARS 6
+
+/*
+ * The longest possible relation path lengths is from the following format:
+ * sprintf(rp.path, "%s/%u/%s/%u/t%d_%u",
+ * PG_TBLSPC_DIR, spcOid,
+ * TABLESPACE_VERSION_DIRECTORY,
+ * dbOid, procNumber, relNumber);
+ *
+ * Note this does *not* include the trailing null-byte, to make it easier to
+ * combine it with other lengths.
+ */
+#define REL_PATH_STR_MAXLEN \
+ ( \
+ sizeof(PG_TBLSPC_DIR) - 1 \
+ + sizeof((char)'/') \
+ + OIDCHARS /* spcOid */ \
+ + sizeof((char)'/') \
+ + sizeof(TABLESPACE_VERSION_DIRECTORY) - 1 \
+ + sizeof((char)'/') \
+ + OIDCHARS /* dbOid */ \
+ + sizeof((char)'/') \
+ + sizeof((char)'t') /* temporary table indicator */ \
+ + PROCNUMBER_CHARS /* procNumber */ \
+ + sizeof((char)'_') \
+ + OIDCHARS /* relNumber */ \
+ + sizeof((char)'_') \
+ + FORKNAMECHARS /* forkNames[forkNumber] */ \
+ )
+
+/*
+ * String of the exact length required to represent a relation path. We return
+ * this struct, instead of char[REL_PATH_STR_MAXLEN + 1], as the pointer would
+ * decay to a plain char * too easily, possibly preventing the compiler from
+ * detecting invalid references to the on-stack return value of
+ * GetRelationPath().
+ */
+typedef struct RelPathStr
+{
+ char str[REL_PATH_STR_MAXLEN + 1];
+} RelPathStr;
+
+
/*
* Stuff for computing filesystem pathnames for relations.
*/
extern char *GetDatabasePath(Oid dbOid, Oid spcOid);
-extern char *GetRelationPath(Oid dbOid, Oid spcOid, RelFileNumber relNumber,
- int procNumber, ForkNumber forkNumber);
+extern RelPathStr GetRelationPath(Oid dbOid, Oid spcOid, RelFileNumber relNumber,
+ int procNumber, ForkNumber forkNumber);
/*
* Wrapper macros for GetRelationPath. Beware of multiple