| From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Refactor function pg_get_multixact_stats (src/backend/utils/adt/multixactfuncs.c) |
| Date: | 2026-07-01 10:44:59 |
| Message-ID: | CAEudQAotZH5xiFQ_iW9Op4T8BT=J+DEb+JOhBN9hoRMKFo2A-Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Michael.
Em qua., 1 de jul. de 2026 às 00:18, Michael Paquier <michael(at)paquier(dot)xyz>
escreveu:
> On Tue, Jun 30, 2026 at 09:23:20AM -0300, Ranier Vilela wrote:
> > Move the GetMultiXactInfo() call and the resulting computations
> > into the branch where the values are actually consumed, narrowing
> > the scope of the related local variables to that branch. This
> > matches the usual pattern for privileged stats functions, which
> > skip the underlying work entirely for callers who can't see the
> > result, and avoids touching shared MultiXact state when there is no
> > caller around to observe it.
>
> That's indeed wasteful, so applied as it is my business.
>
Thanks for the commit.
>
> > While here, size the memset() that NULLs the output row off
> > sizeof(nulls) rather than *sizeof(bool) * tupdesc->natts*.
> > The two are equivalent today, since nulls is a fixed 4-element array
> > matching the function's declared return type, but relying the
> > memset() with *natts* is an unnecessary dependency.
> > If a column were ever added to the function's SQL definition without a
> > matching update to this array, the old code would silently write
> > past the end of nulls.
>
> But I left this one out. It's really impossible to miss.
>
I can send a separate patch.
What do you think?
best regards,
Ranier Vilela
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-07-01 10:54:23 | Re: Refactor function pg_get_multixact_stats (src/backend/utils/adt/multixactfuncs.c) |
| Previous Message | Andrei Lepikhov | 2026-07-01 10:42:53 | Re: RFC: Logging plan of the running query |