Re: Tricky bugs in concurrent index build
От | Tom Lane |
---|---|
Тема | Re: Tricky bugs in concurrent index build |
Дата | |
Msg-id | 18833.1156342177@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Tricky bugs in concurrent index build (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Tricky bugs in concurrent index build
|
Список | pgsql-hackers |
stark <stark@enterprisedb.com> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> [ thinks for a bit... ] At least, it seems hopeless if we use >> SnapshotNow. Does it help if we use a real snapshot? I'm thinking >> pass 1 inserts exactly those tuples that are good according to a >> snap taken at its beginning, and then pass 2 considers only tuples >> that are good according to a snap taken at *its* beginning. But >> having consumed no caffeine yet this morning, I'm not sure I can >> spot any flaws that might exist in this idea. > What about tuples that are inserted and committed in the window between the > two phases. Ie, they're RECENTLY_DEAD but not in phase2's snapshot. We'd put them in the index but skip uniqueness check. > Or do you mean we use SatisfiesVacuum to determine what to insert but > SatisfiesSnapshot to determine whether to check uniqueness? Right. The problems seem to all stem from the risk of trying to unique-check more than one version of a tuple, and using a snap would stop that. We need to think through all the cases though and be sure they all work. regards, tom lane
В списке pgsql-hackers по дате отправления: