Обсуждение: create index concurrently blocked by other query
Hi,
PGv14, it's a time range partition table, we first create index ... on ONLY parent table and it's done very fast, then we are doing "create index concurrently ... on each partition table", then we saw it blocked by some other sessopm "select on other tables" , is it expected ?
from pg_locks, and pg_stat_activity :
for this relation we are creating index concurrently, only "access share" lock by other sessions:
blocked pid 512694:
blocked query： CREATE INDEX CONCURRENTLY IF NOT EXISTS IDX_XMEETINGMETADATA_P202401_xxxID ON xxxxxx_P202401(xxID,SssID); |
blocking pid 90252
blocking query: it's a select from other tables not the one we are creating index concurrently..
SELECT m.Meetingxxx mxxxKey, m.MTGxxxx....,
+
| | | |
+
| | | |
Thanks,
James
James Pang <jamespang886@gmail.com> writes:
> PGv14, it's a time range partition table, we first create index ... on
> ONLY parent table and it's done very fast, then we are doing "create index
> concurrently ... on each partition table", then we saw it blocked by some
> other sessopm "select on other tables" , is it expected ?
Yes, read the documentation. CONCURRENTLY avoids blocking other
transactions, at the cost of being easily blocked itself.
regards, tom lane
You can manage the index maintenance on the OS with Crontab if you want to make it concurrently.
If you only need index maintenance you can schedule it with pg_cron.
The only way to do this is to write a bash script in Linux and insert it with the loop. You can text the bash script for that.
Tom Lane <tgl@sss.pgh.pa.us>, 23 Mar 2024 Cmt, 19:37 tarihinde şunu yazdı:
James Pang <jamespang886@gmail.com> writes:
> PGv14, it's a time range partition table, we first create index ... on
> ONLY parent table and it's done very fast, then we are doing "create index
> concurrently ... on each partition table", then we saw it blocked by some
> other sessopm "select on other tables" , is it expected ?
Yes, read the documentation. CONCURRENTLY avoids blocking other
transactions, at the cost of being easily blocked itself.
regards, tom lane
On Sat, Mar 23, 2024 at 09:29:55PM +0800, James Pang wrote: > Hi, > PGv14, it's a time range partition table, we first create index ... on > ONLY parent table and it's done very fast, then we are doing "create index > concurrently ... on each partition table", then we saw it blocked by some > other sessopm "select on other tables" , is it expected ? Yes. create index will continue its work as soon as all transactions that are started than itself (the create index transaction) will end. Best regards, depesz