Черновик ответа Alvaro:
Álvaro Herrera <[email protected]> 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 <[email protected]>:
> 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/
>
>
>
