mirror of
https://github.com/postgres/postgres.git
synced 2025-11-19 13:42:17 +03:00
37c87e63f9
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
src/backend/access/rmgrdesc/README
WAL resource manager description functions
==========================================
For debugging purposes, there is a "description function", or rmgrdesc
function, for each WAL resource manager. The rmgrdesc function parses the WAL
record and prints the contents of the WAL record in a somewhat human-readable
format.
The rmgrdesc functions for all resource managers are gathered in this
directory, because they are also used in the stand-alone pg_waldump program.
They could potentially be used by out-of-tree debugging tools too, although
neither the description functions nor the output format should be considered
part of a stable API
Guidelines for rmgrdesc output format
-------------------------------------
The goal of these guidelines is to avoid gratuitous inconsistencies across
each rmgr, and to allow users to parse desc output strings without too much
difficulty. This is not an API specification or an interchange format.
(Only heapam and nbtree desc routines follow these guidelines at present, in
any case.)
Record descriptions are similar to JSON style key/value objects. However,
there is no explicit "string" type/string escaping. Top-level { } brackets
should be omitted. For example:
snapshotConflictHorizon: 0, flags: 0x03
Record descriptions may contain variable-length arrays. For example:
nunused: 5, unused: [1, 2, 3, 4, 5]
Nested objects are supported via { } brackets. They generally appear inside
variable-length arrays. For example:
ndeleted: 0, nupdated: 1, deleted: [], updated: [{ off: 45, nptids: 1, ptids: [0] }]
Try to output things in an order that faithfully represents the order of
fields from the underlying physical WAL record struct. Key names should be
unique (at the same nesting level) to make parsing easy. It's a good idea if
the number of items in the array appears before the array.
It's okay for individual WAL record types to invent their own conventions.
For example, Heap2's PRUNE record descriptions use a custom array format for
the record's "redirected" field:
... redirected: [1->4, 5->9], dead: [10, 11], unused: [3, 7, 8]
Arguably the desc routine should be using object notation for this instead.
However, there is value in using a custom format when it conveys useful
information about the underlying physical data structures.
This ad-hoc format has the advantage of being close to the format used for
the "dead" and "unused" arrays (which follow the standard desc convention for
page offset number arrays). It suggests that the "redirected" elements shown
are just pairs of page offset numbers (which is how it really works).
rmgrdesc_utils.c contains some helper functions to print data in this format.