Re: make BuiltinTrancheNames less ugly

2024-03-11 Thread Alvaro Herrera
On 2024-Mar-01, Tristan Partin wrote: > On Fri Mar 1, 2024 at 8:00 AM CST, Alvaro Herrera wrote: > > I'm pretty disappointed of not being able to remove > > generate-lwlocknames.pl (it now generates the .h, no longer the .c > > file), but I can't find a way to do the equivalent #defines in CPP

Re: make BuiltinTrancheNames less ugly

2024-03-01 Thread Tristan Partin
On Fri Mar 1, 2024 at 8:00 AM CST, Alvaro Herrera wrote: On 2024-Feb-23, Heikki Linnakangas wrote: > On 12/02/2024 19:01, Tristan Partin wrote: > > On Wed Jan 24, 2024 at 8:09 AM CST, Alvaro Herrera wrote: > > > IMO it would be less ugly to have the origin file lwlocknames.txt be > > > not a

Re: make BuiltinTrancheNames less ugly

2024-03-01 Thread Alvaro Herrera
On 2024-Feb-23, Heikki Linnakangas wrote: > On 12/02/2024 19:01, Tristan Partin wrote: > > On Wed Jan 24, 2024 at 8:09 AM CST, Alvaro Herrera wrote: > > > IMO it would be less ugly to have the origin file lwlocknames.txt be > > > not a text file but a .h with a macro that can be defined by > > >

Re: make BuiltinTrancheNames less ugly

2024-02-23 Thread Heikki Linnakangas
On 12/02/2024 19:01, Tristan Partin wrote: On Wed Jan 24, 2024 at 8:09 AM CST, Alvaro Herrera wrote: IMO it would be less ugly to have the origin file lwlocknames.txt be not a text file but a .h with a macro that can be defined by interested parties so that they can extract what they want from

Re: make BuiltinTrancheNames less ugly

2024-02-12 Thread Tristan Partin
On Wed Jan 24, 2024 at 8:09 AM CST, Alvaro Herrera wrote: From 3d24b89855888a6650ec1aafb3579d810bfec5ac Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Tue, 23 Jan 2024 10:36:14 +0100 Subject: [PATCH] Remove IndividualLWLockNames We can just merge the lwlock names into the

Re: make BuiltinTrancheNames less ugly

2024-01-24 Thread Alvaro Herrera
On 2024-Jan-23, Alvaro Herrera wrote: > I'm a total newbie to Meson, so it's likely that there are better ways > to implement this. I'll leave this here for a little bit in case > anybody wants to comment. OK, I pushed the array definition, and here's the other bits as a followup patch. I'll

Re: make BuiltinTrancheNames less ugly

2024-01-23 Thread Alvaro Herrera
On 2024-Jan-23, Alvaro Herrera wrote: > ... oh, actually FreeBSD failed with this strange problem while linking: I figured this out. For dtrace support, we need to run dtrace on all the objects produced by the compilation step, but because I took lwlock.o out of the objects used to produce the

Re: make BuiltinTrancheNames less ugly

2024-01-23 Thread Alvaro Herrera
On 2024-Jan-23, Alvaro Herrera wrote: > This is what I came up with. Hm, I forgot the attachment, thanks Heikki for the reminder. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Las mujeres son como hondas: mientras más resistencia tienen, más lejos puedes

Re: make BuiltinTrancheNames less ugly

2024-01-23 Thread Alvaro Herrera
On 2024-Jan-23, Alvaro Herrera wrote: > ... oh, actually FreeBSD failed with this strange problem while linking: > [11:39:43.550] ld: error: undefined symbol: > __dtraceenabled_postgresql___lwlock__wait__start > [11:39:43.551] >>> referenced by lwlock.c:1277 >

Re: make BuiltinTrancheNames less ugly

2024-01-23 Thread Alvaro Herrera
On 2024-Jan-23, Heikki Linnakangas wrote: > On 23/01/2024 12:25, Alvaro Herrera wrote: > > 2. More invasively, rework generate-lwlocknames.pl so that both lwlocks > > and these builtin tranche names appear in a single array. (We could do > > so by #include'ing lwlocknames.c at the top of the

Re: make BuiltinTrancheNames less ugly

2024-01-23 Thread Heikki Linnakangas
On 23/01/2024 12:25, Alvaro Herrera wrote: This array of tranche names is looking pretty ugly these days, and it'll get worse as we add more members to it. I propose to use C99 designated initializers, like we've done for other arrays. Patch attached. The way I've coded in this patch, it

make BuiltinTrancheNames less ugly

2024-01-23 Thread Alvaro Herrera
This array of tranche names is looking pretty ugly these days, and it'll get worse as we add more members to it. I propose to use C99 designated initializers, like we've done for other arrays. Patch attached. The way I've coded in this patch, it means the array will now have 52 NULL pointers at