Re: BUG #18133: Canceling statement due to statement timeout
| От | Greg Sabino Mullane |
|---|---|
| Тема | Re: BUG #18133: Canceling statement due to statement timeout |
| Дата | |
| Msg-id | CAKAnmmJouS1-LLfN5T2+htF9E1WMkwGCQTBYxi0Sd=uAOCx8zQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #18133: Canceling statement due to statement timeout (SOzcn <selahattinozcnma@gmail.com>) |
| Список | 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.
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
> 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 по дате отправления: