You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You may see one of these errors in your Postgres logs, often alongside a failed API request, trigger, or cron job:
cannot find parent statement on pldbgapi2 call stack
pldbgapi2 statement call stack is broken
Both are reported with SQLSTATE XX000 (internal error). They tend to be sporadic, and they appear inside PL/pgSQL functions and triggers, including nested calls. There is often no earlier error logged for the same session. Because they are raised as errors, the current transaction is rolled back unless an exception handler catches them.
Overview
What is happening
Supabase preloads the plpgsql_check library on every project. Older versions of the library keep a stack of the PL/pgSQL statements that are running, and rely on a Postgres function-manager hook to clean up that stack after an error. When the stack gets out of step with what Postgres is running, for example around exceptions or nested calls, the library raises the errors above. The error is sporadic and hard to reproduce, so there is no single query that is known to trigger it.
The code that raises these errors was replaced in plpgsql_check 2.8.6, which no longer uses that hook. You don't need to have the plpgsql_check extension installed to see the error. The library is loaded when Postgres starts, whether or not the extension is created in your database.
Which projects are affected
The library version depends on the Postgres image your project runs:
Postgres image
plpgsql_check in the image
Raises these errors?
Postgres 17: 17.6.1.026 to 17.6.1.101
2.7.11
Yes, reported
Postgres 17: 17.6.1.102 and newer, and the 17.10.1.x and 17.11.0.x lines
2.7.11 and 2.8.11, with 2.8.11 as the default
The code that raises them was removed in 2.8.6
Postgres 15: 15.14.1.026 to 15.14.1.101
2.7.11
Yes, reported
Postgres 15: 15.14.1.102 and newer, including the 15.19.x line
2.7.11 and 2.8.11, with 2.8.11 as the default
The code that raises them was removed in 2.8.6
Older images that predate the versions file, for example 15.8.1.054
2.7.11 or earlier
Yes, reported
Compare your version within its own line. Version numbers are not a single sequence across lines, and some one-off builds differ. For example, 17.6.0.071 already includes 2.8.11.
Version 2.8.11 was added to the images in this release change. You can see which versions an image includes in its versions file.
Look at your Postgres version under Service Versions.
Find it in the table above. If it is in a row where the library can raise these errors, your project runs an affected version.
Solve the problem
Step 1: Upgrade your project
Upgrading moves your project to the latest image, which carries the newer library. We expect an upgrade to resolve the error.
Review the Upgrading guide first, including its pre-requisites. For example, projects with read replicas can't be upgraded until the replicas are deleted, and logical replication slots must be dropped.
Take a backup before you start. For smaller databases, take a logical backup with the pg_dump utility. For larger databases, make sure a recent backup is on the Backups page.
Select Upgrade project on the General settings page. The dashboard shows an estimate of the time required and flags anything that needs attention first.
Plan for downtime. Your project is taken offline during the upgrade, so your database and its associated services are unavailable. The length depends on your database size. If the upgrade fails, your original database is brought back online.
Step 2: Review the functions named in the error
An error entry can include the PL/pgSQL call chain, with the names of the functions and triggers involved. Review those functions and triggers, especially any exception handlers and any code that raises or catches errors. This error can appear without an earlier error in the logs, so you may not find a separate failure to fix.
If your writes conflict with each other, for example concurrent updates recalculating the same row, serializing or batching those writes may reduce how often the error happens. This lowers exposure; it doesn't fix the library.
What you can't change
You can't remove plpgsql_check from shared_preload_libraries. It is configured by the platform for every project, and it isn't among the settings you can override in Customizing Postgres config.
Dropping or never creating the extension makes no difference. The library is loaded when Postgres starts.
Restarting the project doesn't help. The same library version loads again.
There is no documented setting that turns this behavior off.
Confirm the problem is solved
After the upgrade, check your Postgres logs for when the error last occurred. If the last occurrence is from before you upgraded and none have appeared since, the upgrade has likely resolved it. The error is sporadic, so allow a few days of normal traffic before you conclude. If the issue persists after upgrading, let us know with the UTC timestamps of the errors.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Supabase
Uh oh!
There was an error while loading. Please reload this page.
You may see one of these errors in your Postgres logs, often alongside a failed API request, trigger, or cron job:
cannot find parent statement on pldbgapi2 call stackpldbgapi2 statement call stack is brokenBoth are reported with SQLSTATE
XX000(internal error). They tend to be sporadic, and they appear inside PL/pgSQL functions and triggers, including nested calls. There is often no earlier error logged for the same session. Because they are raised as errors, the current transaction is rolled back unless an exception handler catches them.Overview
What is happening
Supabase preloads the
plpgsql_checklibrary on every project. Older versions of the library keep a stack of the PL/pgSQL statements that are running, and rely on a Postgres function-manager hook to clean up that stack after an error. When the stack gets out of step with what Postgres is running, for example around exceptions or nested calls, the library raises the errors above. The error is sporadic and hard to reproduce, so there is no single query that is known to trigger it.The code that raises these errors was replaced in
plpgsql_check2.8.6, which no longer uses that hook. You don't need to have theplpgsql_checkextension installed to see the error. The library is loaded when Postgres starts, whether or not the extension is created in your database.Which projects are affected
The library version depends on the Postgres image your project runs:
plpgsql_checkin the image17.6.1.026to17.6.1.10117.6.1.102and newer, and the17.10.1.xand17.11.0.xlines15.14.1.026to15.14.1.10115.14.1.102and newer, including the15.19.xline15.8.1.054Compare your version within its own line. Version numbers are not a single sequence across lines, and some one-off builds differ. For example,
17.6.0.071already includes 2.8.11.Version 2.8.11 was added to the images in this release change. You can see which versions an image includes in its versions file.
Diagnose the problem
Check your Postgres version
Solve the problem
Step 1: Upgrade your project
Upgrading moves your project to the latest image, which carries the newer library. We expect an upgrade to resolve the error.
pg_dumputility. For larger databases, make sure a recent backup is on the Backups page.Step 2: Review the functions named in the error
An error entry can include the PL/pgSQL call chain, with the names of the functions and triggers involved. Review those functions and triggers, especially any exception handlers and any code that raises or catches errors. This error can appear without an earlier error in the logs, so you may not find a separate failure to fix.
If your writes conflict with each other, for example concurrent updates recalculating the same row, serializing or batching those writes may reduce how often the error happens. This lowers exposure; it doesn't fix the library.
What you can't change
plpgsql_checkfromshared_preload_libraries. It is configured by the platform for every project, and it isn't among the settings you can override in Customizing Postgres config.Confirm the problem is solved
After the upgrade, check your Postgres logs for when the error last occurred. If the last occurrence is from before you upgraded and none have appeared since, the upgrade has likely resolved it. The error is sporadic, so allow a few days of normal traffic before you conclude. If the issue persists after upgrading, let us know with the UTC timestamps of the errors.
Related
plpgsql_check2.7.11 raises cannot find parent statement and statement call stack is brokenAll reactions