Updated

Error: "cannot find parent statement on pldbgapi2 call stack"

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 imageplpgsql_check in the imageRaises these errors?
Postgres 17: 17.6.1.026 to 17.6.1.1012.7.11Yes, reported
Postgres 17: 17.6.1.102 and newer, and the 17.10.1.x and 17.11.0.x lines2.7.11 and 2.8.11, with 2.8.11 as the defaultThe code that raises them was removed in 2.8.6
Postgres 15: 15.14.1.026 to 15.14.1.1012.7.11Yes, reported
Postgres 15: 15.14.1.102 and newer, including the 15.19.x line2.7.11 and 2.8.11, with 2.8.11 as the defaultThe code that raises them was removed in 2.8.6
Older images that predate the versions file, for example 15.8.1.0542.7.11 or earlierYes, 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.

Diagnose the problem

Check your Postgres version

  1. Open Project Settings > General in the Supabase Dashboard.
  2. Look at your Postgres version under Service Versions.
  3. 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.

  1. 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.
  2. 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.
  3. Select Upgrade project on the General settings page. The dashboard shows an estimate of the time required and flags anything that needs attention first.
  4. 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.

AI tools

Connect your AI agentAsk ChatGPTAsk Claude

Go to the GitHub discussion