On Fri, Mar 24, 2023 at 3:31 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Thu, Mar 23, 2023 at 8:10 PM Bharath Rupireddy > <bharath.rupireddyforpostg...@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
