PostgreSQL Flexible Server with VNET Integration to Private Endpoint

Question

PostgreSQL Flexible Server with VNET Integration to Private Endpoint

Michal Kalafarski 45

Hello,
Is there any way to upgrade Azure PostgreSQL Flexible Server with Vnet Integration to server that allows Private Endpoint setup? I was thinking of using migration to new server but then I face below issue:

Error 603413: Unsupported language(s).
The migration service does not support the migration of databases with 'internal' language(s) on the target server. Remove the language(s) and its implemented function(s).

Dump and restore seems a little bit too time consuming as DB is almost 4TB and heavily used in production.

Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-03T14:59:24.55+00:00

Hi @Michal Kalafarski,

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.
Michal Kalafarski 45 Reputation points

2025-03-03T15:18:06.87+00:00
I've run this query:

SELECT proname, lanname FROM pg_proc p JOIN pg_language l ON p.prolang = l.oid WHERE lanname = 'internal';

But it seems only internal PGS functions are there.

Unfortunately I cannot do Network Configuration Adjustments due to company policies assigned to the subscription. Currently connectivity method is set to Public Access (allowed IP addresses) and Private access (VNET integration) is greyed out. And Private Endpoint looks like it's not available to set on existing server (form documentation "Private links cannot be created for servers that have been configured with virtual network integration.")

Looks like the only option would be to dump-restore DB.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-03T15:27:00.5966667+00:00
Hi @Michal Kalafarski,

Thank you for the update.

It seems, you have already done a thorough investigation and identified the constraints you are facing. Given the limitations with network configuration adjustments and the inability to set up a private endpoint on the existing server, the dump and restore method might indeed be the most viable option.

While the dump and restore process can be time-consuming, especially for a large and heavily used production database, there are a few strategies you can employ to minimize downtime and ensure a smooth transition:

Perform the Dump During Off-Peak Hours: Schedule the dump and restore process during a time when the database usage is at its lowest. This can help reduce the impact on your production environment.

Use Parallel Dump and Restore: Utilize parallel dump and restore options to speed up the process. Tools like pg_dump and pg_restore support parallel operations, which can significantly reduce the time required for the dump and restore process.

Incremental Backups: If possible, consider using incremental backups to reduce the amount of data that needs to be transferred. This can help minimize the downtime and speed up the overall process.

I hope this information helps. Please do let us know if you have any further queries.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-04T10:06:44.4166667+00:00

Hi @Michal Kalafarski,

We haven’t heard from you on the last response and wanted to follow up to check if your issue has been resolved.

If you have found a solution, we would appreciate it if you could share it with the community, as it may be helpful to others. Otherwise, please provide more details, and we will do our best to assist you further.
Michal Kalafarski 45 Reputation points

2025-03-04T10:55:36.06+00:00

Proceeding with dump/restore as it seems the only option in my case.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-04T11:59:45.48+00:00

Hi @Michal Kalafarski,

Thank you for the update.

If you have any concerns, please let us know here. We will respond with more details and try to help you.
Michal Kalafarski 45 Reputation points

2025-03-04T13:16:20.9933333+00:00
I've actually gave it one more try and found functions causing the issue with internal language, removal of these functions allowed to trigger Azure built-in migration.

Adding namespace to your query helped to narrow them down:

SELECT n.nspname AS nspname, p.proname AS function_name, l.lanname AS language_name FROM pg_proc p JOIN pg_language l ON p.prolang = l.oid JOIN pg_namespace n ON p.pronamespace = n.oid WHERE l.lanname = 'internal' order by nspname asc;

Thanks @Vijayalaxmi Kattimani for your support.

Accepted answer

0 additional answers

Your answer

Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-03T14:59:24.55+00:00

Hi @Michal Kalafarski,

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.
Michal Kalafarski 45 Reputation points

2025-03-03T15:18:06.87+00:00

I've run this query:

SELECT proname, lanname FROM pg_proc p JOIN pg_language l ON p.prolang = l.oid WHERE lanname = 'internal';

But it seems only internal PGS functions are there.

Unfortunately I cannot do Network Configuration Adjustments due to company policies assigned to the subscription. Currently connectivity method is set to Public Access (allowed IP addresses) and Private access (VNET integration) is greyed out. And Private Endpoint looks like it's not available to set on existing server (form documentation "Private links cannot be created for servers that have been configured with virtual network integration.")

Looks like the only option would be to dump-restore DB.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-03T15:27:00.5966667+00:00

Hi @Michal Kalafarski,

Thank you for the update.

It seems, you have already done a thorough investigation and identified the constraints you are facing. Given the limitations with network configuration adjustments and the inability to set up a private endpoint on the existing server, the dump and restore method might indeed be the most viable option.

While the dump and restore process can be time-consuming, especially for a large and heavily used production database, there are a few strategies you can employ to minimize downtime and ensure a smooth transition:

Perform the Dump During Off-Peak Hours: Schedule the dump and restore process during a time when the database usage is at its lowest. This can help reduce the impact on your production environment.

Use Parallel Dump and Restore: Utilize parallel dump and restore options to speed up the process. Tools like pg_dump and pg_restore support parallel operations, which can significantly reduce the time required for the dump and restore process.

Incremental Backups: If possible, consider using incremental backups to reduce the amount of data that needs to be transferred. This can help minimize the downtime and speed up the overall process.

I hope this information helps. Please do let us know if you have any further queries.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-04T10:06:44.4166667+00:00

Hi @Michal Kalafarski,

We haven’t heard from you on the last response and wanted to follow up to check if your issue has been resolved.

If you have found a solution, we would appreciate it if you could share it with the community, as it may be helpful to others. Otherwise, please provide more details, and we will do our best to assist you further.
Michal Kalafarski 45 Reputation points

2025-03-04T10:55:36.06+00:00

Proceeding with dump/restore as it seems the only option in my case.
Vijayalaxmi Kattimani 1,720 Reputation points Microsoft External Staff

2025-03-04T11:59:45.48+00:00

Hi @Michal Kalafarski,

Thank you for the update.

If you have any concerns, please let us know here. We will respond with more details and try to help you.
Michal Kalafarski 45 Reputation points

2025-03-04T13:16:20.9933333+00:00

I've actually gave it one more try and found functions causing the issue with internal language, removal of these functions allowed to trigger Azure built-in migration.

Adding namespace to your query helped to narrow them down:

SELECT n.nspname AS nspname, p.proname AS function_name, l.lanname AS language_name FROM pg_proc p JOIN pg_language l ON p.prolang = l.oid JOIN pg_namespace n ON p.pronamespace = n.oid WHERE l.lanname = 'internal' order by nspname asc;

Thanks @Vijayalaxmi Kattimani for your support.

Answer 1

Hi Michal Kalafarski,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

As we understand that, you are trying to upgrade Azure PostgreSQL Flexible Server with VNet Integration is configured to allow the setup of Private Endpoints, enabling secure and private connectivity to the server within the virtual network.

Upgrading an Azure PostgreSQL Flexible Server with VNet Integration to support Private Endpoint setup can be somewhat challenging.

The Error 603413: Unsupported language(s) happens because Azure Database Migration Service (DMS) does not support the internal language or custom internal functions when migrating to Flexible Server. To resolve this, you would need to remove the internal languages and their implemented functions before migration. To identify all internal language functions by executing the SQL query provided below. Replace these functions with PL/pgSQL or SQL equivalents wherever possible. Once the modifications are complete, proceed with the migration. However, this might not be feasible for your heavily used 4TB production database.

SELECT proname, lanname 
FROM pg_proc p JOIN pg_language l ON p.prolang = l.oid 
WHERE lanname = 'internal';

Here are a few options you may consider exploring:

Dump and Restore: As you mentioned, this method can be time-consuming, especially for a large database. It involves creating a dump of the database and restoring it on the new server. Given the size and usage of your database, this might not be the most practical solution.
Network Configuration Adjustments: You might want to explore configuring the VNet integration and private endpoint setup directly on your existing server. This involves enabling VNet service endpoint and configuring the virtual network and subnet settings in the Azure portal. This approach might help you avoid the complexities of migration and downtime.

Please refer to the below mentioned link for more information.

https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-networking-private-link

https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-networking-private

I hope this information helps. If the issue still persists, please let us know here. We will respond with more details and try to help you.

If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Share via

PostgreSQL Flexible Server with VNET Integration to Private Endpoint

0 additional answers

Your answer