On Fri, Mar 24, 2023 at 3:31 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Thu, Mar 23, 2023 at 8:10 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> > Yeah, commit [1] removed the last trace of it. I wonder if we can add
> > a WAIT_EVENT_SLRU_FLUSH_SYNC wait event in SlruSyncFileTag(), similar
> > to mdsyncfiletag. This way, we would have covered all sync_syncfiletag
> > fsyncs with wait events.
>
> Ahh, right. Thanks. The mistake was indeed that SlruSyncFileTag
> failed to report it while running pg_fsync().
Thanks. The attached patch looks good to me.
> > > In case it's useful again, here's how I noticed:
> > >
> > > for X in ` grep WAIT_EVENT_ src/include/utils/wait_event.h |
> > > sed '/^#/d;s/,//;s/ = .*//' `
> > > do
> > > if ! ( git grep $X |
> > > grep -v src/include/utils/wait_event.h |
> > > grep -v src/backend/utils/activity/wait_event.c |
> > > grep $X > /dev/null )
> > > then
> > > echo "$X is not used"
> > > fi
> > > done
> >
> > Interesting. It might be an overkill to think of placing it as a
> > compile-time script to catch similar miss-outs in future.
>
> Meh. Parsing C programs from shell scripts is fun for one-off
> throw-away usage, but I think if we want proper automation here we
> should look into a way to define wait events in a central file similar
> to what we do for src/backend/storage/lmgr/lwlocknames.txt. It could
> give the enum name, the display name, and the documentation sentence
> on one tab-separated line, and we could generate all the rest from
> that, or something like that? I suspect that downstream/monitoring
> tools might appreciate the existence of such a file too.
+1. So, with that approach, both wait_event.h and wait_event.c will be
auto-generated I believe.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
