Re: BUG #18133: Canceling statement due to statement timeout - Mailing list pgsql-bugs

From Greg Sabino Mullane
Subject Re: BUG #18133: Canceling statement due to statement timeout
Date
Msg-id CAKAnmmJouS1-LLfN5T2+htF9E1WMkwGCQTBYxi0Sd=uAOCx8zQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18133: Canceling statement due to statement timeout  (SOzcn <selahattinozcnma@gmail.com>)
List pgsql-bugs
> ERROR:  canceling statement due to statement timeout
> STATEMENT:  DROP INDEX dbname."idname"

The problem is likely that you have a prepared transaction, as shown in your startup log:

> 2023-09-25 12:56:27.408 +03 [16513] LOG:  recovering
> prepared transaction 101134325 from shared memory

This transaction will persist across restarts, and can prevent things like a DROP INDEX from being able to complete, hence your eventual timeout.

If you are not actively using prepared transactions, it is highly recommended that you set your max_prepared_transactions setting to 0 in your postgresql.conf file.

To see which transactions you have currently prepared, run:

SELECT * FROM pg_prepared_xacts;

You should see an entry in that view with a transaction of 101134325

At this point, you will need to commit or rollback that transaction. If you don't recognize it or know what it does, I would roll it back:

ROLLBACK PREPARED 'foobar';

Replace the word foobar with whatever value is in the 'gid' column of pg_prepared_xacts

Once that is done, I suspect your DROP INDEX will proceed without a problem.

More information on prepared transactions:

https://www.postgresql.org/docs/current/sql-prepare-transaction.html


Cheers,
Greg

pgsql-bugs by date:

Previous
From: SOzcn
Date:
Subject: Re: BUG #18133: Canceling statement due to statement timeout
Next
From: Andres Freund
Date:
Subject: Re: BUG #18124: PG16 release note document bug in "Add build option to allow testing of small WAL segment sizes"