Re: Avoid orphaned objects dependencies, take 3 - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: Avoid orphaned objects dependencies, take 3
Date
Msg-id CAE9k0PmSuEQ0f8p1SN53W=3on6dPTfVrxs5pjtDCBGOMb=Ehjw@mail.gmail.com
Whole thread Raw
In response to Re: Avoid orphaned objects dependencies, take 3  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Avoid orphaned objects dependencies, take 3
List pgsql-hackers
Hi,

If the dependency is more, this can hit max_locks_per_transaction
limit very fast. Won't it? I just tried this little experiment with
and without patch.

1) created some UDTs (I have just chosen some random number, 15)
do $$
declare
    i int := 1;
    type_name text;
begin
    while i <= 15 loop
        type_name := format('ct_%s', i);

        -- check if the type already exists
        if not exists (
            select 1
            from pg_type
            where typname = type_name
        ) then
            execute format('create type %I as (f1 INT, f2 TEXT);', type_name);
        end if;

        i := i + 1;
    end loop;
end $$;

2) started a transaction and tried creating a table that uses all udts
created above:
begin;
create table dep_tab(a ct_1, b ct_2, c ct_3, d ct_4, e ct_5, f ct_6, g
ct_7, h ct_8, i ct_9, j ct_10, k ct_11, l ct_12, m ct_13, n ct_14, o
ct_15);

3) checked the pg_locks entries inside the transaction both with and
without patch:

-- with patch:
select count(*) from pg_locks;
 count
-------
    23
(1 row)

-- without patch:
select count(*) from pg_locks;
 count
-------
     7
(1 row)

With patch, it increased by 3 times. Won't that create a problem if
many concurrent sessions engage in similar activity?

--
With Regards,
Ashutosh Sharma.



pgsql-hackers by date:

Previous
From: Shubham Khanna
Date:
Subject: Re: Pgoutput not capturing the generated columns
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel CREATE INDEX for GIN indexes