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 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:
- 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);
- 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'
);
- 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);
answered May 30, 2019 at 10:56
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 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 theoid
of the enum you want to change. (UseSELECT * 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 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
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
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
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]
asked Feb 6, 2020 at 18:54
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
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 aVARCHAR
data type. Consider the
following limitations:
You can’t alter a column with compression encodings
BYTEDICT
,
RUNLENGTH
,TEXT255
, orTEXT32K
.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
, orFOREIGN KEY
.You can’t alter columns within a transaction block (
BEGIN ... END
).
For more information about transactions, see Serializable isolation.
answered May 16, 2020 at 18:25
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
-
Marked as answer by