From: | Amul Sul <sulamul(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: "debug_invalidate_system_caches_always" is too long |
Date: | 2021-07-05 05:33:13 |
Message-ID: | CAAJ_b94kvzELLQ5NJuDkUNJezOboPugmwm==ghzMkoCo0wd5=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 5, 2021 at 1:57 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> As I've been poking around in this area, I find myself growing
> increasingly annoyed at the new GUC name
> "debug_invalidate_system_caches_always". It is too d*mn long.
> It's a serious pain to type in any context where you don't have
> autocomplete to help you. I've kept referring to this type of
> testing as CLOBBER_CACHE_ALWAYS testing, even though that name is
> now obsolete, just because it's so much shorter. I think we need
> to reconsider this name while we still can.
>
> I do agree with the "debug_" prefix given that it's now visible to
> users. However, it doesn't seem that hard to save some space in
> the rest of the name. The word "system" is adding nothing of value,
> and the word "always" seems rather confusing --- if it does
> something "always", why is there more than one level? So a simple
> proposal is to rename it to "debug_invalidate_caches".
>
> However, I think we should also give serious consideration to
> "debug_clobber_cache" or "debug_clobber_cache_always" for continuity
> with past practice (though it still feels like "always" is a good
> word to lose now). "debug_clobber_caches" is another reasonable
> variant.
>
> Thoughts?
+1 for the "debug_clobber_caches" variant, easy to remember.
Regards,
Amul
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2021-07-05 05:52:51 | Re: Can a child process detect postmaster death when in pg_usleep? |
Previous Message | Kyotaro Horiguchi | 2021-07-05 04:52:46 | Re: "debug_invalidate_system_caches_always" is too long |