Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWM0a-00EeVz-Jt for pgsql-general@arkaria.postgresql.org; Tue, 23 Jul 2024 20:21:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sWM0Y-00G9gm-EJ for pgsql-general@arkaria.postgresql.org; Tue, 23 Jul 2024 20:21:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sWM0Y-00G9gd-3D for pgsql-general@lists.postgresql.org; Tue, 23 Jul 2024 20:21:14 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sWM0V-0015XV-Tt for pgsql-general@lists.postgresql.org; Tue, 23 Jul 2024 20:21:13 +0000 Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-708adad61f8so3263917a34.1 for ; Tue, 23 Jul 2024 13:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721766071; x=1722370871; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Y5384RF/4JAuET7SymzpAJSTxnGu10yeV3yMa7XU9V8=; b=MUSyoU0Tj9F+zLdp6Z7+C8O+7p3g/s9+AXE8NRHxJCIi1VUCQ4R3BIfb6b05VPrXo1 lhvBPsYMA4t914N65nmqUvYdeQdAVkx+EzPbpUR0ytbo3vJb1fQyta+gIy9P3Hd4Iguk dohA8QbksiTf/mdlpTsB8bE68saS0kTb8EVuoWnmmutbNLj1BePibHekz5JNxkDIkZ6U ktBzN9HIeBDFbWMW6V4piQMmS0T3a9VDGo9YPpC0NhxjLnxTye6+X2z8i+yfKk9+q2ou 6LuxqM966764BHAB6y0aL3tzM7r262A5jxiFTkuFh5M5kFHi2/uRwlA3L3kW7Tu7j+4z 0Lww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721766071; x=1722370871; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y5384RF/4JAuET7SymzpAJSTxnGu10yeV3yMa7XU9V8=; b=dWRA0/aQgM4qr1Ns5tW/MTcucBLHbMto+BnMMkqJjVY54rZPBRTBgSsNmNSBQoQOcm DICjanOi0cHjb8RZFvu2WalF6NMHap1sCoczNsFN/7pQ20VoLGr+EyYIE3PvFa6AJ/rq zixDoSZdQXnv2zr93VXveg/H8RVma8w3jD3KxDqp7HjwHmz9XQ9O0uW70eDTKxOJaOIc FshumgBZsBIjkgvuEPa7jgzGvHb50QpI34yUZOl6i1gbxV0V9+lvy9v+aHOMIbHNyXfL YGlY5sdXdU7H0X95u3McdObU41hGOSYtDvreMVVIqljEbaiQrz4F1Rd8u3YwSIL9gn7u 2z3w== X-Gm-Message-State: AOJu0YwD4uSY3aXKG1tqhRFVGwOu7+s36TlD3Qg2boPJCjxl2tq2U0qT sbm0hCnTfBt37al0xPjZWlHVE30pVsj8gUBrpCpt0gF9GC2MYSzcnLZZakQ9hKxhsUih0fMk01n hc9agkpQ5MA0F//hz7tBA6bybh3jePA== X-Google-Smtp-Source: AGHT+IFLDRZJt2LOEgLB1qc02NVwucI3k7rrw6C3dSLIn57QllUDO96UrSk/sWxqm8RjjuWfi2oW3fTRoj9eTBXZqeA= X-Received: by 2002:a05:6870:c18e:b0:261:86d:89e4 with SMTP id 586e51a60fabf-263ab5f1904mr10104595fac.36.1721766070816; Tue, 23 Jul 2024 13:21:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 23 Jul 2024 16:20:59 -0400 Message-ID: Subject: Re: Issue while creating index dynamically To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000009985f061defe79e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000009985f061defe79e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2024 at 4:10=E2=80=AFPM veem v wrote: > Hi, > It's postgres version 15.4. We have a requirement to create an index on a > big partition table and want to do it online. And to make the script run = in > an automated way on any day , through our ci/cd pipeline we were trying t= o > write it as below inside a begin/end block. I.e. create index using "ON > ONLY" option and then create index on each partition using 'CONCURRENTLY" > key word and then attach the index partitions to the main index, somethin= g > as below. > > But we are getting an error while executing saying it cant be executed in > transaction block with "CONCURRENTLY". So I want to understand , is there > any alternate way to get away with this? > > EXECUTE format('CREATE INDEX %I ON ONLY %I (%I);', index_name, > table_name, column_name); > > FOR partition_name IN > SELECT inhrelid::regclass::text > FROM pg_inherits > WHERE inhparent =3D table_name::regclass > LOOP > partition_index_name :=3D partition_name || '_' || index_name || > '_idx'; > > EXECUTE format(' > CREATE INDEX CONCURRENTLY %I ON %I (%I);', > partition_index_name, partition_name, column_name); > > EXECUTE format(' > ALTER INDEX %I ATTACH PARTITION %I;', index_name, > partition_index_name); > END LOOP; > > ******** > ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block > CONTEXT: SQL statement " > CREATE INDEX CONCURRENTLY partitioned_table_0_index1_idx ON > partitioned_table_0 (id);" > PL/pgSQL function inline_code_block line 20 at EXECUTE > I'd write that in bash, not in a DO block. --00000000000009985f061defe79e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 23, 2024 at 4:10=E2=80=AFPM v= eem v <veema0000@gmail.com>= ; wrote:
Hi,
It's postgres version 15.4= . We have a requirement to create an index on a big partition table and wan= t to do it online. And to make the script=C2=A0run in an automated way on a= ny day , through=C2=A0our ci/cd pipeline we were trying to write it as belo= w inside a begin/end block. I.e. create index using "ON ONLY" opt= ion and then create index on each partition using 'CONCURRENTLY" k= ey word and then attach the index partitions to the main index, something a= s below.=C2=A0

But we are getting an error whi= le executing saying it cant be executed=C2=A0in transaction=C2=A0block with= "CONCURRENTLY". So I want to understand , is there any alternate= way to get away with this?

=C2=A0 EXECUTE = format('CREATE INDEX %I ON ONLY %I (%I);', index_name, table_name, = column_name);

=C2=A0 FOR partition_name IN
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 SELECT inhrelid::regclass::text
=C2=A0 =C2=A0 =C2=A0 =C2=A0 FROM = pg_inherits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WHERE inhparent =3D table_name::= regclass
=C2=A0 =C2=A0 LOOP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 partition_ind= ex_name :=3D partition_name || '_' || index_name || '_idx';=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 EXECUTE format('
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 CREATE INDEX CONCURRENTLY %I ON %I (%I);', = partition_index_name, partition_name, column_name);

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 EXECUTE format('
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 ALTER INDEX %I ATTACH PARTITION %I;', index_name, partition_inde= x_name);
=C2=A0 =C2=A0 END LOOP;


********
ERROR: =C2=A0CREATE INDEX CONCURRENTLY cannot run inside a t= ransaction block
CONTEXT: =C2=A0SQL statement "
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 CREATE INDEX CONCURRENTLY partitioned_table_0_i= ndex1_idx ON partitioned_table_0 (id);"
PL/pgSQL function inline_co= de_block line 20 at EXECUTE

<= div>I'd write that in bash, not in a DO block.
=C2=A0
--00000000000009985f061defe79e--