Active sql transaction 7 error alter type add cannot run inside a transaction block

I am trying to add new type value to my existing types in PostgreSQL. But I get the following error error: ALTER TYPE ... ADD cannot run inside a transaction block The query I used to add a new...

I am trying to add new type value to my existing types in PostgreSQL. But I get the following error

error: ALTER TYPE … ADD cannot run inside a transaction block

The query I used to add a new value to the type is

ALTER TYPE public.request_type ADD VALUE "Check";

I am actually running above query in migrations file which is created using node-pg-migrate

Here public is my schema.

Any idea why this is failing?

Edit:

The below query executes fine when execute it in pgadmin

ALTER TYPE public.request_type ADD VALUE "Check";

But when I run above command through node-pg-migrate migrations it fails and throws above error

asked Nov 5, 2018 at 6:39

Hemadri Dasari's user avatar

Hemadri DasariHemadri Dasari

31.5k34 gold badges116 silver badges157 bronze badges

1

As it was mentioned above you can’t edit enum within transaction block. But you can create the new one. Here are the steps:

  1. Change type from request_type to varchar for all columns/tables which use this type:
ALTER TABLE table_name
    ALTER COLUMN column_name TYPE VARCHAR(255);
  1. Drop and create again request_type enum:
DROP TYPE IF EXISTS request_type;
CREATE TYPE request_type AS ENUM (
    'OLD_VALUE_1',
    'OLD_VALUE_2',
    'NEW_VALUE_1',
    'NEW_VALUE_2'
);
  1. Revert type from varchar to request_type for all columns/tables (revert step one):
ALTER TABLE table_name
    ALTER COLUMN column_name TYPE request_type
    USING (column_name::request_type);

anulaibar's user avatar

answered May 30, 2019 at 10:56

Nasar Kushnir's user avatar

6

The reason is given in the following comment in AlterEnum in src/backend/commands/typecmds.c:

/*
 * Ordinarily we disallow adding values within transaction blocks,
 * because we can't cope with enum OID values getting into indexes and
 * then having their defining pg_enum entries go away.  However, it's
 * okay if the enum type was created in the current transaction, since
 * then there can be no such indexes that wouldn't themselves go away
 * on rollback.  (We support this case because pg_dump
 * --binary-upgrade needs it.)

Note that this restriction has been removed in commit 212fab99; the commit message reads:

To prevent possibly breaking indexes on enum columns, we must keep
uncommitted enum values from getting stored in tables, unless we
can be sure that any such column is new in the current transaction.

Formerly, we enforced this by disallowing ALTER TYPE ... ADD VALUE
from being executed at all in a transaction block, unless the target
enum type had been created in the current transaction.  This patch
removes that restriction, and instead insists that an uncommitted enum
value can't be referenced unless it belongs to an enum type created
in the same transaction as the value.  Per discussion, this should be
a bit less onerous.  It does require each function that could possibly
return a new enum value to SQL operations to check this restriction,
but there aren't so many of those that this seems unmaintainable.

So you might want to upgrade to PostgreSQL v12 some time soon :^)

answered Nov 5, 2018 at 8:18

Laurenz Albe's user avatar

Laurenz AlbeLaurenz Albe

192k17 gold badges177 silver badges233 bronze badges

6

Workaround for earlier versions of PostgreSQL shown here:

Note this will require special permissions because it changes a system table.

  • Replace 'NEW_ENUM_VALUE' with the value you want.
  • Replace'type_egais_units' with the oid of the enum you want to change. (Use SELECT * FROM pg_enum to find the enum you want to update, in my case it was a 5-digit number like '19969')

The statement:

INSERT INTO pg_enum (
    enumtypid, 
    enumlabel, 
    enumsortorder
)
SELECT 
    'type_egais_units'::regtype::oid, 
    'NEW_ENUM_VALUE', 
    (SELECT MAX(enumsortorder) + 1 FROM pg_enum WHERE enumtypid = 'type_egais_units'::regtype)

Of course , upgrading PostgreSQL as suggested in the accepted answer, is probably the best.

Does anyone know how to avoid using transactions when running queries from pgAdmin Version 3.5? (i.e. when executing with F5?)

answered Apr 28, 2019 at 3:23

The Red Pea's user avatar

The Red PeaThe Red Pea

16.7k18 gold badges97 silver badges127 bronze badges

You can change your query to

COMMIT;
ALTER TYPE public.request_type ADD VALUE "Check";

answered Oct 30, 2020 at 6:50

VAG's user avatar

VAGVAG

691 silver badge3 bronze badges

1

Specifically how to do this with node-pg-migrate is to disable transactions for the migration:

exports.up = (pgm) => {
  pgm.noTransaction()
  pgm.addTypeValue('foo', 'BAR', { ifNotExists: true })
}

answered Jun 3, 2021 at 7:53

vesse's user avatar

vessevesse

4,74128 silver badges35 bronze badges

If you changelog in xml format, use <changeSet id="name" author="author" runInTransaction="false">

answered Oct 26, 2022 at 12:52

Anton Vulfert's user avatar

I am trying to alter column in redshift from varchar(30) to varchar(100) Its not working and throwing an error as below:

Command used:

alter table t_name alter column c1 type varchar(300);

Error:

[Amazon](500310) Invalid operation: ALTER TABLE ALTER COLUMN cannot run inside a transaction block; [SQL State=25001, DB Errorcode=500310]

Learning_DBAdmin's user avatar

asked Feb 6, 2020 at 18:54

jagdish's user avatar

2

This Helped me

set autocommit on;
alter table schemaname.tablename alter column columnname type varchar(2000);
set autocommit off;

Solution Found Here

answered Dec 23, 2021 at 11:01

BuzzR's user avatar

BuzzRBuzzR

111 bronze badge

From AWS Documentation, check if you are violating any conditions:

ALTER COLUMN column_name TYPE new_data_type — A clause that changes the
size of a column defined as a VARCHAR data type. Consider the
following limitations:

  • You can’t alter a column with compression encodings BYTEDICT,
    RUNLENGTH, TEXT255, or TEXT32K.

  • You can’t decrease the size less than maximum size of existing data.

  • You can’t alter columns with default values.

  • You can’t alter columns with UNIQUE, PRIMARY KEY, or FOREIGN KEY.

  • You can’t alter columns within a transaction block (BEGIN ... END).
    For more information about transactions, see Serializable isolation.

Rafael Tavares's user avatar

answered May 16, 2020 at 18:25

Faiz's user avatar

FaizFaiz

1012 bronze badges

On Tue, Jul 1, 2014 at 8:48 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Tue, Jul 1, 2014 at 6:52 PM, <feikesteenbergen(at)gmail(dot)com> wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 10822
>> Logged by: Feike Steenbergen
>> Email address: feikesteenbergen(at)gmail(dot)com
>> PostgreSQL version: 9.4beta1
>> Operating system: Debian 3.2.57-3+deb7u2 i686 GNU/Linux
>> Description:
>>
>> When having AUTOCOMMIT disabled, issuing an ALTER SYSTEM reports an error.
>> Enabling AUTOCOMMIT makes the issue disappear.
>>
>> $ psql feike feikesuper -h localhost -p 5433 —no-psqlrc
>> psql (9.4beta1)
>> SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
>> bits: 256)
>> Type «help» for help.
>>
>> feike=# set AUTOCOMMIT off
>> feike=# rollback;
>> WARNING: there is no transaction in progress
>> ROLLBACK
>> feike=# ALTER SYSTEM SET log_min_duration_statement = ‘5s’;
>> ERROR: ALTER SYSTEM cannot run inside a transaction block
>> feike=# rollback;
>> ROLLBACK
>> feike=# set AUTOCOMMIT on
>> feike=# ALTER SYSTEM SET log_min_duration_statement = ‘5s’;
>> ALTER SYSTEM
>>
>>
>>
>> The documentation states:
>>
>> «This command is not allowed inside transaction block or function.»
>>
>> in my understanding, i am not *yet* inside a transaction block when issuing
>> the ALTER SYSTEM, so I assume it would work when having AUTOCOMMIT enabled,
>> but then after a comleted transaction.
>>
>>
>>
>> To me the current behaviour is odd, as VACUUM, which also mentions «VACUUM
>> cannot be executed inside a transaction block.» is able to be executed when
>> having AUTOCOMMIT disabled:
>>
>>
>> $ psql feike feikesuper -h localhost -p 5433 —no-psqlrc
>> psql (9.4beta1)
>> SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
>> bits: 256)
>> Type «help» for help.
>>
>> feike=# set AUTOCOMMIT off
>> feike=# SELECT 1;
>> ?column?
>> ———-
>> 1
>> (1 row)
>>
>> feike=# VACUUM;
>> ERROR: VACUUM cannot run inside a transaction block
>> feike=# rollback;
>> ROLLBACK
>> feike=# set AUTOCOMMIT on
>> feike=# VACUUM;
>> VACUUM
>
> Thanks for the bug report! This problem happens because psql implicitly issues
> BEGIN command before issuing ALTER SYSTEM command when AUTOCOMMIT
> is disabled. But as the document about AUTOCOMMIT says as follows,
> psql should not issue BEGIN in that case. So I think this is the oversight of
> ALTER SYSTEM feature and we should have changed psql so that it doesn’t
> issue BEGIN when it issues ALTER SYSTEM. Attached patch does this.

Committed!

Regards,


Fujii Masao

  • Remove From My Forums
  • Question

  • I have to execute some ALTER TABLE instructions and one ALTER PROCEDURE instruction, all inside a transaction block.

    This was my first implementation:

    BEGIN TRY

    BEGIN TRANSACTION

    ALTER TABLE T_SYNTH_1

    ADD newcolumn

    FLOAT NULL

    GO

    ALTER TABLE T_SYNTH_2

    ADD newcolumn

    FLOAT NULL

    GO

    ALTER PROCEDURE [dbo].[SP_SYNTH_R301]

    (

    @UID_SES INT

    )

    AS

    BEGIN

    END

    GO

    COMMIT TRANSACTION

    END TRY

    BEGIN CATCH

    ROLLBACK TRANSACTION

    END CATCH

    but this returns synthax errors because of the GO instructions. So, because I can’t solve the problem with BEGIN TRY BEGIN TRAN format, I try only with BEGIN TRAN:

    BEGIN TRAN

    GO

    ALTER TABLE T_SYNTH_1

    ADD buba3

    FLOAT NULL

    GO

    ALTER TABLE T_SYNTH_2

    ADD buba3

    FLOAT NULL

    GO

    ALTER PROCEDURE [dbo].[SP_SYNTH_R301]

    (

    @UID_SES INT

    )

    AS

    BEGIN

    END

    GO

    IF (@@ERROR <> 0)

          begin

                ROLLBACK TRAN    

                print(‘ROLLBACK DONE’)

          end

    ELSE

          begin

                COMMIT TRAN

                print(‘COMMIT DONE’)

          end

    GO

    This is fine for synthax and works fine if no errors occured, but if errors occured, this code execute anyway the COMMIT instruction. I think the problem is the @@ERROR variable refers to last batch execution, so before last GO instruction… so in the last block (batch) no errors occured.

    Any idea on how make this transaction query correct?

    Thanks

Answers

  • I can’t uderstand why but it’s so. And so, no errors inserted into temp table e commit is executed.

    you can do the  double check if by inserting  @error  in temp table at the end of each statement after that at the end you can compare the number of no errors ( zero entries) if count is equal to the number of blocks then transaction should be committed else rolled back

    check this

    create table #error (err_number int)

    BEGIN TRAN

    GO

    — statments           

    insert into #error values (@@error) —at the end of each block

    GO

    — statments           

    insert into #error values (@@error) —at the end of each block

    Go

    — statments           

    insert into #error values (@@error) —at the end of each block

    Go

    declare @count int

    select @count = count(*) from #error where err_number <> 0

     IF  @count <> 3 — where 3 is the number of blocks

          begin

                ROLLBACK TRAN    

                print(‘ROLLBACK DONE’)

          end

    ELSE

          begin

                COMMIT TRAN

                print(‘COMMIT DONE’)

          end

    GO

    • Marked as answer by

      Monday, November 2, 2009 5:04 PM

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Active directory проверка на ошибки
  • Active directory rcode name error
  • Active directory ldap error kerio
  • Active directory error 2092
  • Active anticheat lineage ошибка

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии