On Tue, Apr 12, 2022 at 2:03 PM Nathan Bossart <nathandboss...@gmail.com> wrote: > On Tue, Apr 12, 2022 at 10:44:27AM -0700, Andres Freund wrote: > > On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote: > >> Here's a new patch set. I've only changed 0003 as described above. My > >> apologies for the unnecessary round trip. > > > > ISTM we shouldn't apply 0002, 0003 to master before we've branches 15 off.. > > That seems reasonable to me.
Gah, I hate putting this off for another year, but I guess I'm also not convinced that 0003 has the right idea, so maybe it's for the best. Here's what's bugging me: 0003 decrees that _PG_init() is the Wrong Place to Adjust GUC Settings. Now, that begs the question: what is the right place to adjust GUC settings? I argued upthread that extensions shouldn't be overriding values from postgresql.conf at all, but on further reflection I think there's at least one legitimate use case for this sort of thing: some kind of auto-tuning module that, for example, looks at how much memory you have and sets shared_buffers or work_mem or something based on the result. It's arguable how well something like this can actually work, but we probably shouldn't try to prevent people from doing it. I'm a little less clear why Citus thinks this is an appropriate thing for it to do, vs. telling the user to configure a useful value, and I'd be curious to hear an explanation around that. But if there's even one use case where adjusting GUCs at this phase is reasonable, then 0003 isn't really good enough. We need an 0004 that provides a new hook in a place where such changes can safely be made. Meanwhile, committed 0001. -- Robert Haas EDB: http://www.enterprisedb.com