On Thu, Apr 04, 2024 at 11:56:36AM +, Bertrand Drouvot wrote:
> On Thu, Apr 04, 2024 at 07:14:47PM +0900, Michael Paquier wrote:
>> I'd add a "as -this section- has its own C code", for clarity. This
>> just looked a bit strange here.
>
> Sounds good, done that way in v5 attached.
If
Hi,
On Thu, Apr 04, 2024 at 07:14:47PM +0900, Michael Paquier wrote:
> On Thu, Apr 04, 2024 at 09:28:36AM +, Bertrand Drouvot wrote:
> > +# No "Backpatch" region here as code is generated automatically.
> >
> > What about "region here as has its own C code" (that would be more
> >
On Thu, Apr 04, 2024 at 09:28:36AM +, Bertrand Drouvot wrote:
> On Thu, Apr 04, 2024 at 03:50:21PM +0900, Michael Paquier wrote:
>> Is "Backpatch" the best choice we have, though? It speaks by itself
>> but I was thinking about something different, like "Stable". Other
>> ideas or objections
Hi,
On Thu, Apr 04, 2024 at 03:50:21PM +0900, Michael Paquier wrote:
> On Tue, Mar 19, 2024 at 07:34:09AM +, Bertrand Drouvot wrote:
> > I'm not sure as v2 used the "version >= 17" wording which I think would not
> > need
> > manual refresh each time a new stable branch is forked.
> >
> >
On Tue, Mar 19, 2024 at 07:34:09AM +, Bertrand Drouvot wrote:
> I'm not sure as v2 used the "version >= 17" wording which I think would not
> need
> manual refresh each time a new stable branch is forked.
>
> But to avoid any doubt, I'm following your recommendation in v3 attached (then
>
Hi,
On Tue, Mar 19, 2024 at 09:59:35AM +0900, Michael Paquier wrote:
> On Mon, Mar 18, 2024 at 05:57:02PM +, Bertrand Drouvot wrote:
> > Thanks for looking at it!
> > Oh right, the comment is wrong, re-worded in v2 attached.
>
> I've added a couple of fake events in my txt file, and this
On Mon, Mar 18, 2024 at 05:57:02PM +, Bertrand Drouvot wrote:
> Thanks for looking at it!
> Oh right, the comment is wrong, re-worded in v2 attached.
I've added a couple of fake events in my txt file, and this results in
an ordering of the wait events in the docs while the backpatched wait
On Mon, Mar 18, 2024 at 10:24:00AM +0100, Alvaro Herrera wrote:
> FTR I had a rather unpleasant time last week upon finding a wait event
> named PgSleep. If you grep for that, there are no matches at all; and I
> spent ten minutes (for real) trying to figure out where that was coming
> from,
On Mon, Mar 18, 2024 at 08:49:34AM -0700, Noah Misch wrote:
> On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
>> +# Ensure that the wait events under the "Backpatch" delimiter are placed in
>> the
>> +# same order as in the pre 17 wait_event_types.h (see VERSION_FILE_SYNC as
>>
Hi,
On Mon, Mar 18, 2024 at 08:49:34AM -0700, Noah Misch wrote:
> On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
> > --- a/src/backend/utils/activity/wait_event_names.txt
> > +++ b/src/backend/utils/activity/wait_event_names.txt
> > @@ -24,7 +24,12 @@
> > # SGML tables of
On Mon, Mar 18, 2024 at 09:04:44AM +, Bertrand Drouvot wrote:
> --- a/src/backend/utils/activity/wait_event_names.txt
> +++ b/src/backend/utils/activity/wait_event_names.txt
> @@ -24,7 +24,12 @@
> # SGML tables of wait events for inclusion in the documentation.
> #
> # When adding a
On 2023-Aug-28, Michael Paquier wrote:
> I have looked again at that, and switching wait_event_names.txt to use
> two columns made of the typedef definitions and the docs like is not a
> problem:
> FOO_BAR "Waiting on Foo Bar."
>
> WAIT_EVENT_ is appended to the typedef definitions in the
Hi,
On Mon, Mar 18, 2024 at 08:02:24AM +0900, Michael Paquier wrote:
> On Sun, Mar 17, 2024 at 11:31:14AM -0700, Noah Misch wrote:
> > Adding an event
> > will renumber others, which can make an extension report the wrong event
> > until
> > recompiled. Extensions citus, pg_bulkload, and vector
On Mon, Mar 18, 2024 at 08:02:24AM +0900, Michael Paquier wrote:
> > 1. Don't back-patch wait events to v17+. Use the closest existing event.
> > 2. Let wait_event_names.txt back-patches control the enum order. For
> > example,
> >a line could have an annotation that controls its position
On Sun, Mar 17, 2024 at 11:31:14AM -0700, Noah Misch wrote:
> I like the new developer experience of adding a wait event. After release of
> v17, how should we approach back-patching an event, like was done in commits
> 8fa4a1a 1396b5c 78c0f85? Each of those commits put the new event at the end
On Wed, Jul 05, 2023 at 10:57:19AM +0900, Michael Paquier wrote:
> I have applied it.
I like the new developer experience of adding a wait event. After release of
v17, how should we approach back-patching an event, like was done in commits
8fa4a1a 1396b5c 78c0f85? Each of those commits put the
Hi,
On 9/6/23 5:44 AM, Michael Paquier wrote:
On Wed, Sep 06, 2023 at 04:20:23AM +0200, Erik Wienhold wrote:
FYI: https://en.wikipedia.org/wiki/Sentence_spacing
That was an interesting read. Thanks.
+1, thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source
On Wed, Sep 06, 2023 at 04:20:23AM +0200, Erik Wienhold wrote:
> FYI: https://en.wikipedia.org/wiki/Sentence_spacing
That was an interesting read. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 05, 2023 at 11:06:36AM +0200, Drouvot, Bertrand wrote:
> Also, v5 needs a rebase due to f691f5b80a.
>
> Attaching v6 taking care of the 2 points mentioned above.
Thanks. This time I have correctly checked the consistency of the
data produced across all these commits using
On 05/09/2023 13:50 CEST Michael Paquier wrote:
> On Tue, Sep 05, 2023 at 11:06:36AM +0200, Drouvot, Bertrand wrote:
> > Oh ok, out of curiosity, why are 2 whitespaces intentional?
>
> That depends on the individual who write the code, but I recall that
> this is some old-school style from the
On Tue, Sep 05, 2023 at 11:06:36AM +0200, Drouvot, Bertrand wrote:
> Oh ok, out of curiosity, why are 2 whitespaces intentional?
That depends on the individual who write the code, but I recall that
this is some old-school style from the 70's and/or the 80's when
typing machines were still
Hi,
On 9/5/23 7:44 AM, Michael Paquier wrote:
On Mon, Sep 04, 2023 at 02:14:58PM +0200, Drouvot, Bertrand wrote:
# Build the descriptions. There are in camel-case.
# LWLock and Lock classes do not need any modifications.
Nit: 2 whitespaces before "There are in camel"
The
On Mon, Sep 04, 2023 at 02:14:58PM +0200, Drouvot, Bertrand wrote:
> # Build the descriptions. There are in camel-case.
> # LWLock and Lock classes do not need any modifications.
>
> Nit: 2 whitespaces before "There are in camel"
The whitespaces are intentional, the typo in the first
Hi,
On 8/29/23 8:41 AM, Michael Paquier wrote:
On Tue, Aug 29, 2023 at 08:17:10AM +0200, Drouvot, Bertrand wrote:
That may be a bug in the matrix because of bb90022, as git am can be
easily pissed.
git am does not complain anymore.
+ # Generate the element name for the enums based on
On Tue, Aug 29, 2023 at 02:21:48PM +0200, Alvaro Herrera wrote:
> Yeah, I have a mild preference for keeping the prefix, but it's mild
> because I also imagine that if somebody doesn't see the full symbol name
> when grepping they will think to remove the prefix. So only -0.1.
So, are you fine
On 2023-Aug-29, Michael Paquier wrote:
> On Tue, Aug 29, 2023 at 08:17:10AM +0200, Drouvot, Bertrand wrote:
> > Agree that done that way one could easily grep the events from the
> > source code and match them with wait_event_names.txt. Then I don't
> > think the "search" issue in the code is
On Tue, Aug 29, 2023 at 08:17:10AM +0200, Drouvot, Bertrand wrote:
> Agree that done that way one could easily grep the events from the
> source code and match them with wait_event_names.txt. Then I don't
> think the "search" issue in the code is still a concern with the
> current proposal.
It
Hi,
On 8/28/23 10:04 AM, Michael Paquier wrote:
On Mon, Jul 17, 2023 at 10:16:02AM +0900, Michael Paquier wrote:
So you mean to switch a line that now looks like that:
WAIT_EVENT_FOO_BAR FooBar"Waiting on Foo Bar."
To that:
FOO_BAR "Waiting on Foo Bar."
Or even that:
On Mon, Jul 17, 2023 at 10:16:02AM +0900, Michael Paquier wrote:
> So you mean to switch a line that now looks like that:
> WAIT_EVENT_FOO_BAR FooBar"Waiting on Foo Bar."
> To that:
> FOO_BAR "Waiting on Foo Bar."
> Or even that:
> WAIT_EVENT_FOO_BAR "Waiting on Foo Bar."
>
> Sure,
On Sun, Jul 16, 2023 at 12:21:20PM -0700, Andres Freund wrote:
> I think the search issue is valid, so I do think going the other way is
> preferrable. I.e. use just the enum value in the .txt and generate the camel
> case name from that. That allows you to search the define used in code and
>
Hi,
On 2023-07-14 13:49:22 +0900, Michael Paquier wrote:
> I have looked again at 0001 and 0002 and applied them to get them out
> of the way. 0003 and 0004 are rebased and attached. I'll add them to
> the CF for later consideration. More opinions are welcome.
> From
On Thu, Jul 13, 2023 at 10:26:54AM +0900, Michael Paquier wrote:
> I would like to apply 0001 and 0002 to improve the format if there are
> no objections. 0003 and 0004 are still here for discussion, as it
> does not seem like a consensus has been reached for that yet. Getting
> more opinions
On Mon, Jul 10, 2023 at 07:52:23AM +0200, Drouvot, Bertrand wrote:
> On 7/10/23 7:20 AM, Michael Paquier wrote:
>> Hmm. Something like that could be done, for instance:
>>
>> # src/backend/utils/activity/wait_event_types.h
>> -# typedef enum definitions for wait events.
>> +#
On 7/11/23 12:52 AM, Michael Paquier wrote:
On Mon, Jul 10, 2023 at 09:11:36AM +0200, Alvaro Herrera wrote:
I don't like this bit, because it means the .txt file is now ungreppable
as source of the enum name. Things become mysterious and people have to
track down the event name by reading
On Mon, Jul 10, 2023 at 09:11:36AM +0200, Alvaro Herrera wrote:
> I don't like this bit, because it means the .txt file is now ungreppable
> as source of the enum name. Things become mysterious and people have to
> track down the event name by reading the the Perl generating script.
> It's
On 2023-Jul-09, Michael Paquier wrote:
> Patch 0002 introduces a set of simplifications for the format of
> wait_event_names.txt:
> - Removal of the first column for the enums.
I don't like this bit, because it means the .txt file is now ungreppable
as source of the enum name. Things become
On 7/10/23 7:20 AM, Michael Paquier wrote:
On Mon, Jul 10, 2023 at 07:05:30AM +0200, Drouvot, Bertrand wrote:
Yeah there is one in generate-wait_event_types.pl. I was wondering
to add one in wait_event_names.txt too (as this is the place where
no wait events would be added if any).
Hmm.
On Mon, Jul 10, 2023 at 07:05:30AM +0200, Drouvot, Bertrand wrote:
> Yeah there is one in generate-wait_event_types.pl. I was wondering
> to add one in wait_event_names.txt too (as this is the place where
> no wait events would be added if any).
Hmm. Something like that could be done, for
Hi,
On 7/9/23 9:36 AM, Michael Paquier wrote:
On Sun, Jul 09, 2023 at 09:15:34AM +0200, Drouvot, Bertrand wrote:
I also noticed that you now provide the culprit line in case of parsing
failure (thanks for that).
Yes, that's mentioned in the commit message I quickly wrote in 0002.
#
-#
On Sun, Jul 09, 2023 at 09:15:34AM +0200, Drouvot, Bertrand wrote:
> I also noticed that you now provide the culprit line in case of parsing
> failure (thanks for that).
Yes, that's mentioned in the commit message I quickly wrote in 0002.
> #
> -# "C symbol in enums" "format in the system
Hi,
On 7/9/23 6:32 AM, Michael Paquier wrote:
On Fri, Jul 07, 2023 at 01:49:24PM +0900, Michael Paquier wrote:
Hmm. If we go down this road I would make the choice of simplicity
and remove entirely a column, then, generating the snakecase from the
camelcase or vice-versa (say like a $string
On Fri, Jul 07, 2023 at 01:49:24PM +0900, Michael Paquier wrote:
> Hmm. If we go down this road I would make the choice of simplicity
> and remove entirely a column, then, generating the snakecase from the
> camelcase or vice-versa (say like a $string =~ s/([a-z]+)/$1_/g;),
> even if it means
On Thu, Jul 06, 2023 at 06:19:43PM -0700, Andres Freund wrote:
> On 2023-07-06 09:36:12 +0900, Michael Paquier wrote:
>> So you mean renaming the existing events like WalSenderWaitForWAL to
>> WalSenderWaitForWal?
>
> Yes.
>
>> The impact on existing monitoring queries is not zero because any
Hi,
On 2023-07-06 09:36:12 +0900, Michael Paquier wrote:
> On Wed, Jul 05, 2023 at 02:59:39PM -0700, Andres Freund wrote:
> > Rebasing a patch over this I was a bit confused because I got a bunch of
> > ""unable to parse wait_event_names.txt" errors. Took me a while to figure
> > out
> > that
On Wed, Jul 05, 2023 at 02:59:39PM -0700, Andres Freund wrote:
> Rebasing a patch over this I was a bit confused because I got a bunch of
> ""unable to parse wait_event_names.txt" errors. Took me a while to figure out
> that that was just because I didn't include a trailing . in the description.
>
Hi,
On 2023-07-05 10:57:19 +0900, Michael Paquier wrote:
> With all that in place, VPATH builds, the CI, meson, configure/make
> and the various cleanup targets were working fine, so I have applied
> it. Now let's see what the buildfarm tells.
>
> The final --stat number is like that:
> 22
On Tue, Jul 04, 2023 at 09:34:33AM +0200, Drouvot, Bertrand wrote:
> Yeah, with "capture" set to "false" then ninja alldocs does not error out
> and wait_event_types.sgml gets generated.
>
> I'll look at the extra options --code and --docs.
+wait_event_types.sgml:
Hi,
On 7/3/23 9:11 AM, Michael Paquier wrote:
On Mon, Jul 03, 2023 at 03:57:42PM +0900, Michael Paquier wrote:
Thanks for looking at it and having fixed the issues that were present in
v10.
I think that we should add some options to the perl script to be more
selective with the files
On Mon, Jul 03, 2023 at 03:57:42PM +0900, Michael Paquier wrote:
> I think that we should add some options to the perl script to be more
> selective with the files generated. How about having two options
> called --docs and --code to select one or the other, then limit what
> gets generated in
On Thu, May 18, 2023 at 01:36:30PM +0900, Michael Paquier wrote:
> The order looks fine seen from here, thanks!
Now that v17 is open for business, I have looked again at this patch.
perlcritic is formulating three complaints:
./src/backend/utils/activity/generate-waiteventtypes.pl: Loop iterator
On Wed, May 17, 2023 at 11:10:21AM +0200, Drouvot, Bertrand wrote:
> Sorry did not pay enough attention to it ;-(
No problem.
> Yeap, done in V10 for sgml and the C part too (for consistency).
The order looks fine seen from here, thanks!
--
Michael
signature.asc
Description: PGP signature
On Wed, May 17, 2023 at 08:31:53AM +0200, Drouvot, Bertrand wrote:
> Did it that way in V9 attached and the sorting does look like what
> we expect now.
Yes, the order of the items in the individual tables is fine, but this
is still a bit incorrect for the classes? Note that the tables for
the
On Mon, May 15, 2023 at 06:45:23PM +0200, Drouvot, Bertrand wrote:
> On 5/6/23 4:37 AM, Michael Paquier wrote:
>> On Sat, May 06, 2023 at 11:23:17AM +0900, Michael Paquier wrote:
I'll look at v7 when the v17 branch opens and propose the separate patch
mentioned above at that time too.
Hi,
On 5/6/23 4:23 AM, Michael Paquier wrote:
On Thu, May 04, 2023 at 08:39:49AM +0200, Drouvot, Bertrand wrote:
On 5/1/23 1:59 AM, Michael Paquier wrote:
I'm not sure I like it. First, it does break the "Note" ordering as compare
to the current documentation. That's not a big deal though.
On Sat, May 06, 2023 at 11:23:17AM +0900, Michael Paquier wrote:
>> I'll look at v7 when the v17 branch opens and propose the separate patch
>> mentioned above at that time too.
>
> Thanks, again.
By the way, while browsing through the patch, I have noticed two
things:
- The ordering of the
On Thu, May 04, 2023 at 08:39:49AM +0200, Drouvot, Bertrand wrote:
> On 5/1/23 1:59 AM, Michael Paquier wrote:
> I'm not sure I like it. First, it does break the "Note" ordering as compare
> to the current documentation. That's not a big deal though.
>
> Secondly, what If we need to add some
Hi,
On 5/2/23 4:50 AM, Thomas Munro wrote:
[patch]
This is not a review of the perl/make/meson glue/details, but I just
wanted to say thanks for working on this Bertrand & Michael, at a
quick glance that .txt file looks like it's going to be a lot more fun
to maintain!
Thanks Thomas! Yeah
Hi,
On 5/1/23 1:59 AM, Michael Paquier wrote:
On Fri, Apr 28, 2023 at 02:29:13PM +0200, Drouvot, Bertrand wrote:
On 4/27/23 8:13 AM, Michael Paquier wrote:
But do we need to merge more data than necessary? We could do things
in the simplest fashion possible while making the docs and code
> [patch]
This is not a review of the perl/make/meson glue/details, but I just
wanted to say thanks for working on this Bertrand & Michael, at a
quick glance that .txt file looks like it's going to be a lot more fun
to maintain!
On Fri, Apr 28, 2023 at 02:29:13PM +0200, Drouvot, Bertrand wrote:
> On 4/27/23 8:13 AM, Michael Paquier wrote:
>> Generating the contents of Lock would mean to gather in a single file
>> the data for the generation of LockTagType in lock.h, the list of
>> LockTagTypeNames in lockfuncs.c and the
On Wed, Apr 26, 2023 at 08:36:44PM +0200, Drouvot, Bertrand wrote:
> Please find attached V5 addressing the previous comments except
> the "ordering" one (need to look deeper at this).
I was putting my hands into that, and I see now what you mean here..
Among the nine types of wait events, Lock,
Hi,
On 4/26/23 6:51 PM, Drouvot, Bertrand wrote:
Hi,
On 4/25/23 7:15 AM, Michael Paquier wrote:
Will do, no problem at all.
Please find attached V5 addressing the previous comments except
the "ordering" one (need to look deeper at this).
Regards,
--
Bertrand Drouvot
PostgreSQL
Hi,
On 4/25/23 7:15 AM, Michael Paquier wrote:
On Mon, Apr 24, 2023 at 09:03:53AM +0200, Drouvot, Bertrand wrote:
Oh right, fixed.
I may tweak a few things if I put my hands on it, but that looks
pretty solid seen from here..
Glad to hear! ;-)
I have spotted a few extra issues.
One
On Mon, Apr 24, 2023 at 09:03:53AM +0200, Drouvot, Bertrand wrote:
> Oh right, fixed.
I may tweak a few things if I put my hands on it, but that looks
pretty solid seen from here.. I have spotted a few extra issues.
One thing I have noticed with v4 is that the order of the tables
generated in
Hi,
On 4/24/23 5:15 AM, Michael Paquier wrote:
On Sat, Apr 22, 2023 at 03:36:05PM +0200, Drouvot, Bertrand wrote:
On 4/20/23 3:09 AM, Michael Paquier wrote:
It is clear that the format of the file is:
- category
- C symbol in enums.
- Format in the system views.
- Description in the docs.
Or
On Sat, Apr 22, 2023 at 03:36:05PM +0200, Drouvot, Bertrand wrote:
> On 4/20/23 3:09 AM, Michael Paquier wrote:
>> It is clear that the format of the file is:
>> - category
>> - C symbol in enums.
>> - Format in the system views.
>> - Description in the docs.
>> Or perhaps it would be better to
Hi,
On 4/20/23 3:09 AM, Michael Paquier wrote:
On Wed, Mar 29, 2023 at 02:51:27PM +0200, Drouvot, Bertrand wrote:
Just realized that more polishing was needed.
Done in V2 attached.
That would be pretty cool to get that done in an automated way, I've
wanted that for a few years now. And I
On Wed, Mar 29, 2023 at 02:51:27PM +0200, Drouvot, Bertrand wrote:
> Just realized that more polishing was needed.
>
> Done in V2 attached.
That would be pretty cool to get that done in an automated way, I've
wanted that for a few years now. And I guess that a few others have
the same feeling
On Thu, Mar 30, 2023 at 12:41:27PM -0400, Corey Huinker wrote:
> I think this is good work, but I can't help thinking it would be easier to
> understand and maintain if we used a template engine like Text::Template,
> and filled out the template with the variant bits. I'll ask that question
> in
On Wed, Mar 29, 2023 at 8:51 AM Drouvot, Bertrand <
bertranddrouvot...@gmail.com> wrote:
> Hi,
>
> On 3/29/23 11:44 AM, Drouvot, Bertrand wrote:
>
> >
> > Looking forward to your feedback,
>
> Just realized that more polishing was needed.
>
> Done in V2 attached.
>
> Regards,
>
> --
> Bertrand
Hi,
On 3/29/23 11:44 AM, Drouvot, Bertrand wrote:
Looking forward to your feedback,
Just realized that more polishing was needed.
Done in V2 attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.comFrom
Hi hackers,
In another thread [1], Thomas had the idea to $SUBJECT in a similar way
to what is currently done with src/backend/storage/lmgr/lwlocknames.txt.
Doing so, like in the attached patch proposal, would help to avoid:
- wait event without documentation like observed in [2]
- orphaned
72 matches
Mail list logo
