| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
| Date: | 2021-07-18 05:17:28 |
| Message-ID: | A74C56AE-FA8A-4BBD-8941-06AA8FED73E1@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> 18 июля 2021 г., в 01:12, Noah Misch <noah(at)leadboat(dot)com> написал(а):
>
> Suppose some transaction has a vxid but no xid. Shortly after
> GetLockConflicts(), it acquires an xid, modifies the table, and issues PREPARE
> TRANSACTION. Could that cause a corrupt index even with this diff?
Firstly I've tried to stress things out. This little go program [0] easily reproduces corruption on patched code.
Meanwhile vxid->xid->2px program does not [1] (both patched and unpatched).
I think CIC does not care much about VXIDs at all. It's only important when real XID started: before GetLockConflicts() or after.
Thanks!
Best regards, Andrey Borodin.
[0] https://gist.github.com/x4m/8b6025995eedf29bf588727375014dfc#file-stress-xid-2px
[1] https://gist.github.com/x4m/8b6025995eedf29bf588727375014dfc#file-stress-vxid-xid-2px
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pawel Kudzia | 2021-07-18 08:27:32 | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
| Previous Message | Thomas Munro | 2021-07-18 05:13:50 | Re: BUG #16696: Backend crash in llvmjit |