| 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: | Whole Thread | Raw Message | 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.
| 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 |