Allow to control the order of shared_preload_libraries (citus)

[ratranqu]

The citus extension needs to be loaded first when bringing up a cluster. The current implementation allows customising the extensions loaded, but extensions provided by the resource definition will be loaded after any internal ones.

Therefore, we updated the implementation such that the extension list order will be driven by the shared_preload_libraries list when present.

When your definition has a shared_preload_libraries list containing one of the internally loaded libraries, the extension order will change to take the order from the shared_preload_libraries list. This may change the behaviour of existing definitions when the shared_preload_libraries contains one of the internally loaded libraries.

When there shared_preload_libraries list contains one or more or the internal extensions, the duplicate internal extensions will be ignored, which allows the user to fully define the order of loading of extensions.

Issue: #3194

[cbandy]

🔧 This will need tests before it can merge. Perhaps here or a new dedicated one:

postgres-operator/internal/patroni/config_test.go

Line 156 in 2171bfe

func TestDynamicConfiguration(t *testing.T) {

This looks like it will unblock the referenced issue, but I do want to point out that there is still no way to communicate "front of list" with this. Yes, setting citus,pgaudit indicates "citus before pgaudit", but that may not always resolve to the front of the list.

🤔 I also want to consider security boundaries here. One of the reasons PGO puts pgaudit early is to try to audit as much as possible. Prior to this PR, there is no way to disrupt the placement of pgaudit.

[cbandy]

that may not always resolve to the front of the list

Sorry, as written, it does. But I'm still thinking about pgaudit and "mandatory" and how we might want those to be "ahead" of things.

[ratranqu]

@cbandy thx for the feedback. I have added two tests which cover ordering and the preventing of duplication.

Furthermore, I realised that I misrepresented what is happening in the original PR description (updated). Indeed, we only change the location of the internally loaded extensions if they are redefined in the shared_preload_libraries. Sorry about that, the change has been done a few weeks ago.

I think that might address part of your security concerns in so far as the default behaviour remains the same unless there is an explicit intent of changing the order of internally loaded extension.

[ratranqu]

Is there anything I can help with to take this forward or is there no interest for this change at this stage?

[tunatoksoz]

Also interested - looking to activate citus, like @ratranqu

[tony-landreth]

@ratranqu Thank you for your PR. We have plans to provide a solution to specifically support Citus.

[ratranqu]

@ratranqu Thank you for your PR. We have plans to provide a solution to specifically support Citus.

Awesome! Any sort of timeframe? Happy to beta test if useful!

[tunatoksoz]

Any guesses on the timeframe?

[tunatoksoz]

@tony-landreth hey tony / crunchydata team - any guesses on timeframe? Really appreciate it.

[cbandy]

We took a different approach in #3761 to specifically accommodate the citus library. Please let me know if that doesn't resolve things or if there are other extensions that need to be loaded a certain way. Thanks!