Jelte Fennema e29db74a19 Don't override postgres C symbols with our own (#6300) ... When introducing our overrides of pg_cancel_backend and pg_terminate_backend we accidentally did that in such a way that we cannot call the original pg_cancel_backend and pg_terminate_backend from C anymore. This happened because we defined the exact same symbols in our shared library as postgres does in its own binary. This fixes that by using a different names for the C function than for the SQL function. Making this work in all upgrade and downgrade scenarios is not trivial though, because we actually need to remove the C function definition. Postgres errors in two different times when the symbol that a C function wants to call is not defined in the library it expects it in: 1. When creating the SQL function definition 2. When calling the SQL function Item 1 causes an issue when creating our extension for the first time. We then go execute all the migrations that we have. So if the 11.0 migration contains a SQL function definition that still references the pg_cancel_backend symbol, that migration will fail. This issue is solved by actually changing the SQL definition in the old migration. This is not enough to fix all issues though. Item 2 causes an issue after an upgrade to 11.1, because it won't have the new definition of the SQL function. This is solved by recreating the SQL functions in the migration to 11.1. That way it gets the new definition. Then finally there's the case of downgrades. To continue to make our pg_cancel_backend SQL function work after downgrading, we will need to make a patch release for 11.0 that includes the new citus_cancel_backend symbol. This is done in a separate commit.		2022-09-07 11:27:05 +02:00
..
11.0-1.sql	Don't override postgres C symbols with our own (#6300)	2022-09-07 11:27:05 +02:00
latest.sql	Don't override postgres C symbols with our own (#6300)	2022-09-07 11:27:05 +02:00