Maintaining huge part of the core code

[danolivo]

Hi everyone!

I hope that someone in the community has already made mistakes that I can learn from and avoid. I need to maintain a significant portion of the Postgres core code, patched a little bit. What is the most effective and time-saving approach to maintain this for different core versions? It's important to keep in mind that core code can be changed in minor updates, and we need to track those changes, copy the new version, and reapply the patches.

[yrashk]

I haven't had to do this on the scale of Postgres, but I suspect there's not much you can do beyond maintaining a golden patchset backported to the versions of interest. I would love to be proven wrong, though!

[danolivo]

Maybe I was unclear. My issue is that I need to maintain a large part of the patched vanilla code (it is okay; I will survive). But that code contains exported functions/variables, and I want to use it without interfering with the same functions that exist in the core.
To be more specific, I want to change (a little bit) my. It can be called by planner_hook as an alternative to the original one, but 99.99% of the code is exactly the same.
So, the question is simple: how to compile, link, and load such code as an extension without intersecting with the core and how to maintain this process. Maybe some massive extensions have already passed through it and have experience with it.

[yrashk]

Ah! You want to have modified copies of existing functionality in your extension?

Abstractly, on the runtime side, I don't think you'll run into a problem because those symbols that you copied, to the best of my understanding, will only be resolved from within the shared library and will have no effect on other users the Postgres process

Now, compile-time it could be trickier as the linker needs to know what to link to. It is platform-dependent (macOS linking, for example, actually links against the target binary – the bundle loader), with Linux the referenced symbols are undefined until runtime. So I guess if you override them, they will be resolved locally.

[danolivo]

I remember the case when two extensions exported variables with the same name but different values. After loading, both extensions used the variable from an extension that was loaded later. That's why I thought about a trick to isolate all exported symbols in the library because it will be a lot of duplicated exported objects. Maybe it is possible to clean up the library interface after linking? I am dreaming ;), but who knows, may such tricks exist?

[yrashk]

Was it a regular variable (symbol), renedezvous variable, or something like a GUC?

[danolivo]

It was declared as "extern PGDLLIMPORT ". Not a GUC or something else. Just variable with some common functionality, like 'library_mode'.