Re: Support to define custom wait events for extensions

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tristan Partin <tristan(at)neon(dot)tech>
Cc: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, hlinnaka(at)iki(dot)fi
Subject: Re: Support to define custom wait events for extensions
Date: 2023-07-19 23:34:05
Message-ID: ZLhy7ct0o0LQBUR4@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 19, 2023 at 11:16:34AM -0500, Tristan Partin wrote:
> On Tue Jul 11, 2023 at 6:29 PM CDT, Michael Paquier wrote:
>> This style comes from LWLockRegisterTranche() in lwlock.c. Do you
>> think that it would be more adapted to change that to
>> pg_nextpower2_size_t() with a Size? We could do that for the existing
>> code on HEAD as an improvement.
>
> Yes, I think that would be the most correct code. At the very least,
> using a uint32 instead of an int, would be preferrable.

Would you like to send a patch on a new thread about that?

>> Hmm, okay, that would nice to hear about to make sure that the
>> approach taken on this thread is able to cover what you are looking
>> for. So you mean that Neon has been using something similar to
>> register wait events in the backend? Last time I looked at the Neon
>> repo, I did not get the impression that there was a custom patch for
>> Postgres in this area. All the in-core code paths using
>> WAIT_EVENT_EXTENSION would gain from the APIs added here, FWIW.
>
> I did some investigation into the Neon fork[0], and couldn't find any
> commits that seemed related. Perhaps this is on our wishlist instead of
> something we already have implemented. I have CCed Heikki to talk some
> more about how this would fit in at Neon.
>
> [0]: https://github.com/neondatabase/postgres

Anybody with complex out-of-core extensions have wanted more
monitoring capabilities for wait events without relying on the core
backend. To be honest, I would not be surprised to see this stuff on
more than one wishlist.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2023-07-19 23:44:31 Re: [PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans
Previous Message Michael Paquier 2023-07-19 23:19:13 Re: Requiring recovery.signal or standby.signal when recovering with a backup_label