Robert Haas <robertmhaas@gmail.com> writes:
> I wouldn't say that approach is wrong. I think we're just prioritizing
> different things. I think that the pattern of wanting to request
> shared memory in _PG_init() is common, and there are lots of
> extensions that already do it that way, and if we pursue this plan,
> then all of those extensions really ought to be updated to use the new
> hook, including pg_prewarm and pg_stat_statements. They may continue
> to work if they don't, but they'll be doing something that is not
> really best practice any more but will happen to work until you make
> your request for shared memory dependent on the wrong thing, or until
> you load up another module at the same time that tweaks some GUC upon
> which your calculation depends (imagine an autotuner that adjusts
> pg_stat_statements.max at startup time). So I think we'll be
> inflicting subtle bugs on extension authors that will never really get
> fully sorted out.
Yeah, there is something to be said for preventing subtle interactions
between extensions.
> So in the end I see basically four possibilities here:
> A. No hard compatibility break, but invent a set-a-GUC hook that runs earlier.
> B. No hard compatibility break, but invent a request-shmem hook that runs later.
> C. Invent a set-a-GUC hook that runs earlier AND refuse to set GUCs in _PG_init.
> D. Invent a request-shmem hook that runs later AND refuse to accept
> shmem requests in _PG_init.
I dislike A for the reason I already stated: _PG_init should be the
first code we run in an extension. Not doing that is just too hacky
for words. While B breaks the least stuff in the short run, I agree
that it leaves extension authors on the hook to avoid unpleasant
interactions, and that the only way they can be sure to do so is
to move their shmem requests to the new hook. So if we're willing
to accept a hard compatibility break to prevent such bugs, then
I too prefer D to C. What I'm not quite convinced about is whether
the problem is big enough to warrant a compatibility break.
regards, tom lane
