From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: WIP: new system catalog pg_wait_event |
Date: | 2023-08-19 10:00:05 |
Message-ID: | ZOCSpcueqMduuJJ5@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 19, 2023 at 11:35:01AM +0200, Drouvot, Bertrand wrote:
> Hi,
>
> On 8/18/23 12:31 PM, Michael Paquier wrote:
> Thanks! Please find attached v9 fixing this typo.
I was looking at v8, and this looks pretty good to me. I have
spotted a few minor things.
+ proretset => 't', provolatile => 's', prorettype => 'record',
This function should be volatile. For example, a backend could add a
new wait event while a different backend queries twice this view in
the same transaction, resulting in a different set of rows sent back.
By the way, shouldn't the results of GetWaitEventExtensionNames() in
the SQL function be freed? I mean that:
for (int idx = 0; idx < nbextwaitevents; idx++)
pfree(waiteventnames[idx]);
pfree(waiteventnames);
+ /* Handling extension custom wait events */
Nit warning: s/Handling/Handle/, or "Handling of".
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-08-19 10:09:20 | Re: [PoC] pg_upgrade: allow to upgrade publisher node |
Previous Message | Drouvot, Bertrand | 2023-08-19 09:35:01 | Re: WIP: new system catalog pg_wait_event |