Re: Can concurrent create index concurrently block each other?

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can concurrent create index concurrently block each other?
Date: 2023-10-16 06:32:21
Message-ID: cac8e252-d209-4ef6-8e2b-26a9f0efe94c@garret.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 15/10/2023 10:59 pm, Tom Lane wrote:
> Konstantin Knizhnik <knizhnik(at)garret(dot)ru> writes:
>> One our customer complains that he spawned two `create index
>> concurrently` for two different tables and both stuck in"waiting for old
>> snapshots".
>> I wonder if two CIC can really block each other in `WaitForOlderSnapshots`?
> Since v14, we won't wait for another CIC unless it is processing a
> partial or expressional index. (According to the comments for
> WaitForOlderSnapshots, anyway.) What PG version is this, and what
> kind of indexes are being rebuilt?
>
> In any case, if they were blocking each other that would be reported
> as a deadlock, since they'd use VirtualXactLock() which relies on
> the heavyweight lock manager. What seems more likely is that your
> customer had some other old transaction sitting idle and blocking both
> of them. Looking into pg_locks would provide more definitive evidence
> about what they are waiting for.

Sorry, for false alarm. We have found long running truncation which
actually blocks CIC in this case.
I have asked this question because customer has wrote that there was no
other long living active transactions, but it was not true.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-10-16 07:16:37 Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag
Previous Message Bowen Shi 2023-10-16 06:21:07 Re: Requiring recovery.signal or standby.signal when recovering with a backup_label