postgres

History

David Rowley f0efa5aec1 Introduce the concept of read-only StringInfos There were various places in our codebase which conjured up a StringInfo by manually assigning the StringInfo fields and setting the data field to point to some existing buffer. There wasn't much consistency here as to what fields like maxlen got set to and in one location we didn't correctly ensure that the buffer was correctly NUL terminated at len bytes, as per what was documented as required in stringinfo.h Here we introduce 2 new functions to initialize StringInfos. One allows callers to initialize a StringInfo passing along a buffer that is already allocated by palloc. Here the StringInfo code uses this buffer directly rather than doing any memcpying into a new allocation. Having this as a function allows us to verify the buffer is correctly NUL terminated. StringInfos initialized this way can be appended to and reset just like any other normal StringInfo. The other new initialization function also accepts an existing buffer, but the given buffer does not need to be a pointer to a palloc'd chunk. This buffer could be a pointer pointing partway into some palloc'd chunk or may not even be palloc'd at all. StringInfos initialized this way are deemed as "read-only". This means that it's not possible to append to them or reset them. For the latter of the two new initialization functions mentioned above, we relax the requirement that the data buffer must be NUL terminated. Relaxing this requirement is convenient in a few places as it can save us from having to allocate an entire new buffer just to add the NUL terminator or save us from having to temporarily add a NUL only to have to put the original char back again later. Incompatibility note: Here we also forego adding the NUL in a few places where it does not seem to be required. These locations are passing the given StringInfo into a type's receive function. It does not seem like any of our built-in receive functions require this, but perhaps there's some UDT out there in the wild which does require this. It is likely worthy of a mention in the release notes that a UDT's receive function mustn't rely on the input StringInfo being NUL terminated. Author: David Rowley Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvorfO3iBZ%3DxpiZvp3uHtJVLyFaPBSvcAhAq2HPLnaNSwQ%40mail.gmail.com		2 years ago
..
activity	Fix typos in wait_event.c	2 years ago
adt	Introduce the concept of read-only StringInfos	2 years ago
cache	Add support event triggers on authenticated login	2 years ago
error	Avoid calling proc_exit() in processes forked by system().	2 years ago
fmgr	Fix code indentation violations introduced by recent commit	2 years ago
hash	Update copyright for 2023	3 years ago
init	Add support event triggers on authenticated login	2 years ago
mb	Doc: improve cross-reference in Makefile comment.	2 years ago
misc	Remove useless self-joins	2 years ago
mmgr	Shrink memory contexts struct sizes	2 years ago
resowner	Pre-beta mechanical code beautification.	3 years ago
sort	Add const to values and nulls arguments	2 years ago
time	Improve error message for snapshot import in snapmgr.c, take two	2 years ago
.gitignore	…
Gen_dummy_probes.pl	Pre-beta mechanical code beautification.	3 years ago
Gen_dummy_probes.pl.prolog	Update copyright for 2023	3 years ago
Gen_dummy_probes.sed	Update copyright for 2023	3 years ago
Gen_fmgrtab.pl	Pre-beta mechanical code beautification.	3 years ago
Makefile	Update copyright for 2023	3 years ago
README.Gen_dummy_probes	…
errcodes.txt	Remove the "snapshot too old" feature.	2 years ago
generate-errcodes.pl	Pre-beta mechanical code beautification.	3 years ago
meson.build	Update copyright for 2023	3 years ago
postprocess_dtrace.sed	Update copyright for 2023	3 years ago
probes.d	bufmgr: Introduce infrastructure for faster relation extension	3 years ago

README.Gen_dummy_probes

# Generating dummy probes

If Postgres isn't configured with dtrace enabled, we need to generate
dummy probes for the entries in probes.d, that do nothing.

This is accomplished in Unix via the sed script `Gen_dummy_probes.sed`. We
used to use this in MSVC builds using the perl utility `psed`, which mimicked
sed. However, that utility disappeared from Windows perl distributions and so
we converted the sed script to a perl script to be used in MSVC builds.

We still keep the sed script as the authoritative source for generating
these dummy probes because except on Windows perl is not a hard requirement
when building from a tarball.

So, if you need to change the way dummy probes are generated, first change
the sed script, and when it's working generate the perl script. This can
be accomplished by using the perl utility s2p.

s2p is no longer part of the perl core, so it might not be on your system,
but it is available on CPAN and also in many package systems. e.g.
on Fedora it can be installed using `cpan App::s2p` or
`dnf install perl-App-s2p`.

The Makefile contains a recipe for regenerating Gen_dummy_probes.pl, so all
you need to do is once you have s2p installed is `make Gen_dummy_probes.pl`
Note that in a VPATH build this will generate the file in the vpath tree,
not the source tree.