| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Goel, Dhruv" <goeldhru(at)amazon(dot)com> |
| Cc: | Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY |
| Date: | 2019-06-09 15:36:37 |
| Message-ID: | 8370.1560094597@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Goel, Dhruv" <goeldhru(at)amazon(dot)com> writes:
> Yes, you are correct. The test case here was that if a tuple is inserted after the reference snapshot is taken in Phase 2 and before the index is marked ready. If this tuple is deleted before the reference snapshot of Phase 3, it will never make it to the index. I have fixed this problem by making pg_index tuple updates transactional (I believe there is no reason why it has to be in place now) so that the xmin of the pg_index tuple is same the xmin of the snapshot in Phase 3.
I think you are mistaken that doing transactional updates in pg_index
is OK. If memory serves, we rely on xmin of the pg_index row for purposes
such as detecting whether a concurrently-created index is safe to use yet.
So a transactional update would restart that clock and result in temporary
denial of service.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-06-09 15:40:00 | Re: Avoiding deadlock errors in CREATE INDEX CONCURRENTLY |
| Previous Message | Tom Lane | 2019-06-09 15:21:09 | Re: Use of reloptions by EXTENSIONs |