plpgsql not working on Postgres 16.8 for Flexi server

Question

plpgsql not working on Postgres 16.8 for Flexi server

Alex 25

Hello. Recently our demo database was automatically upgraded to Postgres 16.8.

This immediately caused an issue where dropping, creating and migrating the database causes a new error.

PG::FeatureNotSupported: ERROR: extension "plpgsql" is not allow-listed for "azure_pg_admin" users in Azure Database for PostgreSQL (PG::FeatureNotSupported)

If you follow the options for support, you find a section explaining the following:

plpgsql We have currently disabled the available to control on plpgsql extensions (removed from azure.extensions), because it is enabled by default and utilized internally for other operations and extensions, so removing this extension will also remove any dependencies it has on other operations and extensions. Make sure you are removing this extension from your template if you are explicitlys using to prevent any conflict in your deployment.

This explains that you don't need to enable the extension because it's already enabled. However, the above error clearly shows it is not enabled (or if it is, it is not accessible by the user).

How do we resolve this?

Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-17T17:23:27.8566667+00:00
Hi @ Alex

You're right — in Azure Database for PostgreSQL Flexible Server, the plpgsql extension is preloaded and used internally, which is why it's not listed in azure.extensions and can't be added or removed manually. However, in Postgres 16.8 on Flexible Server, we’ve seen cases where the azure_pg_admin user runs into this error when dropping or recreating the database due to access limitations around plpgsql.

Even though plpgsql is available and used by default, certain operations like CREATE EXTENSION for plpgsql can trigger a FeatureNotSupported error because the extension is not explicitly allow-listed for azure_pg_admin.

You don't need to manually create or drop the plpgsql extension — it’s already there. If your migration or DB setup scripts explicitly try to do this (e.g., DROP EXTENSION IF EXISTS plpgsql; or CREATE EXTENSION plpgsql;), removing those lines might resolve the issue.

Update your migration scripts to avoid manually managing the plpgsql extension.

You can check its status with:

SELECT * FROM pg_extension WHERE extname = 'plpgsql';

If you're using a custom template that’s trying to remove plpgsql, make sure it's cleaned up or corrected before deploying.

I hope this information helps. Please do Upvote if this suggestion helps.
Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-18T20:06:28.4666667+00:00

Hi @ Alex

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution

please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Andy B 0 Reputation points

2025-04-18T21:23:14.0666667+00:00

We don't always have the option to modify the code of the applications we are deploying. Without the ability to modify the code, and without the ability to allowlist the extension, we can't use a flexible server for our deployment. We ran into this issue today as well, and the application we are trying to use doesn't allow us to modify the query
Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-21T16:53:52.05+00:00

Hi @ Andy B

If Flexible Server's limitations are blocking your deployment, you could evaluate other Azure database offerings, such as Hyperscale (Citus), which might better align with your application's requirements.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Alex 25 Reputation points

2025-04-22T10:18:53.65+00:00
Hi @Sai Raghunadh M , thanks for your reply. It was a four day holiday here so only now back at the office.

I appreciate your ability to clarify some of the points around this PLPGSQL extension, being:

The extension is now enabled by default.

The extension is for internal use only, and cannot be accessed by our applications.

Any schemas should be updated to remove reference to plpgsql.

However, we do have some places that use raw SQL that rely on plpgsql features such as procedures and functions.

When we started using these for Azure Database for PostgreSQL flexible servers version 15, there was no indication it would be turned off in the next version!

What can we do to rectify application access to this extension?
Alex 25 Reputation points

2025-04-22T10:19:12.47+00:00

I am wondering if we missed the memo explaining this, although that's something to consider for the future, not now. Right now the priority is getting out application in a state where we can get back to continuous deployment.

Accepted answer

1 additional answer

Your answer

Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-17T17:23:27.8566667+00:00

Hi @ Alex

You're right — in Azure Database for PostgreSQL Flexible Server, the plpgsql extension is preloaded and used internally, which is why it's not listed in azure.extensions and can't be added or removed manually. However, in Postgres 16.8 on Flexible Server, we’ve seen cases where the azure_pg_admin user runs into this error when dropping or recreating the database due to access limitations around plpgsql.

Even though plpgsql is available and used by default, certain operations like CREATE EXTENSION for plpgsql can trigger a FeatureNotSupported error because the extension is not explicitly allow-listed for azure_pg_admin.

You don't need to manually create or drop the plpgsql extension — it’s already there. If your migration or DB setup scripts explicitly try to do this (e.g., DROP EXTENSION IF EXISTS plpgsql; or CREATE EXTENSION plpgsql;), removing those lines might resolve the issue.

Update your migration scripts to avoid manually managing the plpgsql extension.

You can check its status with:

SELECT * FROM pg_extension WHERE extname = 'plpgsql';

If you're using a custom template that’s trying to remove plpgsql, make sure it's cleaned up or corrected before deploying.

I hope this information helps. Please do Upvote if this suggestion helps.
Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-18T20:06:28.4666667+00:00

Hi @ Alex

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution

please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Andy B 0 Reputation points

2025-04-18T21:23:14.0666667+00:00

We don't always have the option to modify the code of the applications we are deploying. Without the ability to modify the code, and without the ability to allowlist the extension, we can't use a flexible server for our deployment. We ran into this issue today as well, and the application we are trying to use doesn't allow us to modify the query
Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-21T16:53:52.05+00:00

Hi @ Andy B

If Flexible Server's limitations are blocking your deployment, you could evaluate other Azure database offerings, such as Hyperscale (Citus), which might better align with your application's requirements.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Alex 25 Reputation points

2025-04-22T10:18:53.65+00:00

Hi @Sai Raghunadh M , thanks for your reply. It was a four day holiday here so only now back at the office.

I appreciate your ability to clarify some of the points around this PLPGSQL extension, being:

The extension is now enabled by default.

The extension is for internal use only, and cannot be accessed by our applications.

Any schemas should be updated to remove reference to plpgsql.

However, we do have some places that use raw SQL that rely on plpgsql features such as procedures and functions.

When we started using these for Azure Database for PostgreSQL flexible servers version 15, there was no indication it would be turned off in the next version!

What can we do to rectify application access to this extension?
Alex 25 Reputation points

2025-04-22T10:19:12.47+00:00

I am wondering if we missed the memo explaining this, although that's something to consider for the future, not now. Right now the priority is getting out application in a state where we can get back to continuous deployment.

Answer 1

Hi @ Alex

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer.

Issue:

Recently our demo database was automatically upgraded to Postgres 16.8.

This immediately caused an issue where dropping, creating and migrating the database causes a new error.

PG::FeatureNotSupported: ERROR: extension "plpgsql" is not allow-listed for "azure_pg_admin" users in Azure Database for PostgreSQL (PG::FeatureNotSupported)

If you follow the options for support, you find a section explaining the following:

plpgsql We have currently disabled the available to control on plpgsql extensions (removed from azure.extensions), because it is enabled by default and utilized internally for other operations and extensions, so removing this extension will also remove any dependencies it has on other operations and extensions. Make sure you are removing this extension from your template if you are explicitlys using to prevent any conflict in your deployment.

This explains that you don't need to enable the extension because it's already enabled. However, the above error clearly shows it is not enabled (or if it is, it is not accessible by the user).

How do we resolve this?

Solution:

By adding this line to our migration code, we avoid the issue on environments that need to migrate the database from the start.

class EnableExtensions < ActiveRecord::Migration[6.0]
  def change
    enable_extension 'uuid-ossp'
    enable_extension 'pgcrypto'
    enable_extension 'plpgsql' unless extension_enabled?('plpgsql') # modified line
  end
end

It did take a lot of work to get there, but this seems to be the smallest amount needed.

Interestingly loading the schema doesn't have the same error, even though it also enabled the extension. Perhaps Postgres knows it's already enabled so doesn't bother.

If you have any other questions or are still running into more issues, please let me know. Thank you again for your time and patience throughout this issue.

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Alex 25 Reputation points

2025-04-23T08:56:23.8033333+00:00

Thanks @Sai Raghunadh M .

Now that the immediate issue is solved, do you have any idea why this change was made, and why we didn't receive any communication around it?

Answer 2

Alex 25

An interesting conclusion.

Initially we thought we needed to turn plpgsql off in our migrations and schema, but it turns out Azure is essentially complaining about our attempts to interact at all with the configuration of the extension.

By adding this line to our migration code, we avoid the issue on environments that need to migrate the database from the start.

class EnableExtensions < ActiveRecord::Migration[6.0]
  def change
    enable_extension 'uuid-ossp'
    enable_extension 'pgcrypto'
    enable_extension 'plpgsql' unless extension_enabled?('plpgsql') # modified line
  end
end

It did take a lot of work to get there, but this seems to be the smallest amount needed.

Interestingly loading the schema doesn't have the same error, even though it also enabled the extension. Perhaps Postgres knows it's already enabled so doesn't bother.

Sai Raghunadh M 3,155 Reputation points Microsoft External Staff

2025-04-22T16:27:18.18+00:00

Hi @ Alex

Glad to know that your issue has been resolved. And thanks for sharing the solution, which might be beneficial to other community members reading this thread.
nch 0 Reputation points

2025-04-25T14:46:46.7733333+00:00

Thanks for figuring this out. It does make you think: who at MS thought it's a good idea to roll out a breaking change like this without any form of warning? These things happen too often...

Share via

plpgsql not working on Postgres 16.8 for Flexi server

1 additional answer

Your answer