Build warning with meson and dtrace on Fedora 43

Hi, Laurenz!
Thanks for the report. I tried to fix the patch in the attachment.
---
Regards,
Rachitskiy Andrey

пт, 24 июл. 2026 г. в 11:04, Laurenz Albe <laurenz.albe@cybertec.at>:

On 2026-Jul-24, Laurenz Albe wrote:

When I build with meson/ninja with pretty much everything enabled
and dtrace, I get the following warning:

[40/2412] Generating src/include/utils/probes.h.tmp with a custom command
Warning: /usr/bin/dtrace:.dtrace-temp.cf7b554c.d:68: syntax error near:
probe smgr__md__read__start

Warning: Proceeding as if --no-pyparsing was given.

I don't get the warning when I build with configure/make.

"git bisect" identifies the following commit as culprit:

ca326e903d "Clean up read() return type" by Peter E.

I don't know enough about dtrace to track this down, but I think it
should be fixed.

That's weird. The only change that seems near enough in that commit was

diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c
index 718c1cfc0f9..79febf12de3 100644
--- a/src/backend/storage/smgr/md.c
+++ b/src/backend/storage/smgr/md.c
@@ -863,7 +863,7 @@ mdreadv(SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum,
 		struct iovec iov[PG_IOV_MAX];
 		int			iovcnt;
 		pgoff_t		seekpos;
-		int			nbytes;
+		ssize_t		nbytes;
 		MdfdVec    *v;
 		BlockNumber nblocks_this_segment;
 		size_t		transferred_this_segment;

But then, variable 'nbytes' is not used by the probe mentioned in the
error message. It is used by the probe two lines below:

src/backend/storage/smgr/md.c:
TRACE_POSTGRESQL_SMGR_MD_READ_START(forknum, blocknum,
reln->smgr_rlocator.locator.spcOid,
reln->smgr_rlocator.locator.dbOid,
reln->smgr_rlocator.locator.relNumber,
reln->smgr_rlocator.backend);
nbytes = FileReadV(v->mdfd_vfd, iov, iovcnt, seekpos,
WAIT_EVENT_DATA_FILE_READ);
TRACE_POSTGRESQL_SMGR_MD_READ_DONE(forknum, blocknum,
reln->smgr_rlocator.locator.spcOid,
reln->smgr_rlocator.locator.dbOid,
reln->smgr_rlocator.locator.relNumber,
reln->smgr_rlocator.backend,
nbytes,
size_this_segment - transferred_this_segment);

I wonder if changing the first 'long long int' to ssize_t in
src/backend/utils/probes.d for smgr__md__read__done would fix it:

     probe smgr__md__read__start(ForkNumber, BlockNumber, Oid, Oid, Oid, int);
-    probe smgr__md__read__done(ForkNumber, BlockNumber, Oid, Oid, Oid, int, long long int, long long int);
+    probe smgr__md__read__done(ForkNumber, BlockNumber, Oid, Oid, Oid, int, ssize_t, long long int);

(Making that one nbytes back to int from ssize_t in md.c and seeing if
that silences the warning would also be a way to be more certain that
this is the code that the warning is about.)

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

Черновик ответа Alvaro:

Álvaro Herrera <alvherre@kurilemu.de> writes:

That's weird. The only change that seems near enough in that commit was
... nbytes from int to ssize_t in md.c ...

But then, variable 'nbytes' is not used by the probe mentioned in the
error message.

The confusing part is the warning text itself.
SystemTap's dtrace(1) fails while parsing the *next* probe and
reports the name of the last probe it successfully parsed.
So "syntax error near: probe smgr__md__read__start" really means it
choked on smgr__md__read__done just below.
ca326e903d also changed probes.d in the same commit:
```
-       probe smgr__md__read__done(..., int, int, int);
+       probe smgr__md__read__done(..., int, long long int, long long int);
```
(and 1f8c504e308 did the same for smgr__md__write__done).  That is
what triggers the warning.  The md.c ssize_t change is unrelated to
probes.h generation; reverting nbytes to int would not silence it.

I checked this on Fedora 43 with systemtap-sdt-devel 5.5:
- long long int, long long int -> warning
- int, int -> clean
- ssize_t, long long int -> warning (still has long long int)
- long, long -> clean

So using ssize_t for only the first of those two arguments is not
enough. ssize_t, ssize_t would satisfy SystemTap's parser, but
probes.d already documents that we should not use system typedefs
there (they break on macOS). "long" matches ssize_t on the LP64
platforms where we support DTrace, and is already used by
sort__done.
The patch I sent earlier switches both trailing arguments of
smgr__md__{read,write}__done to long (and updates the docs).

---
Regards,
Rachitskiy Andrey

пт, 24 июл. 2026 г. в 11:43, Álvaro Herrera <alvherre@kurilemu.de>:

On Fri, 2026-07-24 at 11:27 +0500, Andrey Rachitskiy wrote:

Thanks for the report. I tried to fix the patch in the attachment.

I can confirm that the patch fixes the warning on my side.

Yours,
Laurenz Albe

This seems to me to be a fundamentally broken, hence short-lived
workaround. I think we need another way. As you mention upthread,
we document that system-header types such as ssize_t should not be
used in probes.d because "they cause compilation errors on macOS".
But I tried it just now and it compiles fine on current Tahoe.
Maybe that note is obsolete?

Agreed that "long" was only papering over SystemTap's parser. v2 uses
the real call-site types instead:
```
probe smgr__md__read__done(..., int, ssize_t, size_t);
probe smgr__md__write__done(..., int, ssize_t, size_t);
```

nbytes is ssize_t (and can be negative: we fire the probe before the
nbytes < 0 check). The "bytes requested" argument is
size_this_segment - transferred_this_segment, which is size_t.
ssize_t, ssize_t would also silence SystemTap, but wouldn't match md.c.

On the probes.d note: it originally named Mac OS X 10.5 (e04810e8c4).
The concrete complaints from that era were about uintptr_t / uint32_t
and about needing #define rather than typedef for our PG aliases
(Robert Lor). da6c4f6ca88 only rebranded the wording to "macOS 10.5";
later ff43b3e88ec dropped the "10.5" while touching the nearby bool
#define, without re-checking the restriction. ssize_t and size_t, by
contrast, are first-class types in Apple's DTrace typedef tables.
Your Tahoe result fits that; I don't have a Mac here to re-check
myself. I've revised the note to warn against multi-word types like
"long long int" (what SystemTap rejects) rather than blanket-banning
system typedefs.

Verified on Fedora 43 / systemtap-sdt-devel: unpatched probes.d still
gets the pyparsing fallback warning; with ssize_t, size_t both
dtrace -C -h and meson probes.h generation are clean, as is a full
configure --enable-dtrace build.

---
Regards,
Rachitskiy Andrey

ср, 29 июл. 2026 г. в 09:14, Tom Lane <tgl@sss.pgh.pa.us>:

So "avoid multiword type names" is both too general and not enough
to keep out of trouble. [...] I'm inclined to write something like
"Use only system-supplied type names, e.g., write uint64_t not uint64;
macOS' dtrace rejects the latter. Also avoid "long long int", as
SystemTap's dtrace fails on that specific spelling."

I've
rewritten the probes.d note along those lines and kept ssize_t/size_t
for the smgr probes (system-supplied, matching md.c).

Updated patch attached.

ср, 29 июл. 2026 г. в 20:42, Tom Lane <tgl@sss.pgh.pa.us>:

Andrey Rachitskiy <pl0h0yp1@gmail.com> writes:

I've
rewritten the probes.d note along those lines and kept ssize_t/size_t
for the smgr probes (system-supplied, matching md.c).

Updated patch attached.

Pushed with minor additional comment-smithing. I also double-checked
that macOS's current behavior applies at least as far back as
macOS 14 (Sonoma), so we should be good on any version that anyone
is likely to install PG 20 on.

I noticed that we had

#define bool unsigned char

in there, and tried to get rid of that, reasoning that now that we
use <stdbool.h> "bool" does not mean "unsigned char". However, macOS
rejects "bool", so I desisted. Thinking twice, it looks like we
could instead do

#define bool _Bool

but that seems like a matter for a separate patch, perhaps.

BTW, I realized that we had no buildfarm coverage of --enable-dtrace
on macOS, so I've enabled that on indri.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Pushed with minor additional comment-smithing. I also double-checked
that macOS's current behavior applies at least as far back as
macOS 14 (Sonoma), so we should be good on any version that anyone
is likely to install PG 20 on.

[...]

BTW, I realized that we had no buildfarm coverage of --enable-dtrace
on macOS, so I've enabled that on indri.

Thanks for pushing, and for the extra comment polish.
Having --enable-dtrace enabled on indri should help catch macOS-specific
issues sooner.

чт, 30 июл. 2026 г. в 05:33, Tom Lane <tgl@sss.pgh.pa.us>:

Andrey Rachitskiy <pl0h0yp1@gmail.com> writes:

I've
rewritten the probes.d note along those lines and kept ssize_t/size_t
for the smgr probes (system-supplied, matching md.c).

Updated patch attached.

Pushed with minor additional comment-smithing. I also double-checked
that macOS's current behavior applies at least as far back as
macOS 14 (Sonoma), so we should be good on any version that anyone
is likely to install PG 20 on.

I noticed that we had

#define bool unsigned char

in there, and tried to get rid of that, reasoning that now that we
use <stdbool.h> "bool" does not mean "unsigned char". However, macOS
rejects "bool", so I desisted. Thinking twice, it looks like we
could instead do

#define bool _Bool

but that seems like a matter for a separate patch, perhaps.

BTW, I realized that we had no buildfarm coverage of --enable-dtrace
on macOS, so I've enabled that on indri.

regards, tom lane

--
Regards,
Rachitskiy Andrey