Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
| От | Antonin Houska |
|---|---|
| Тема | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Дата | |
| Msg-id | 5784.1764580169@localhost обсуждение исходный текст |
| Ответ на | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
| Ответы |
Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
|
| Список | pgsql-hackers |
Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > I'm a bit worried, though, that LR may lose updates due to commit > order differences between WAL and PGPROC. I don't know how that's > handled in logical decoding, and can't find much literature about it > in the repo either. Can you please give me an example of this problem? I understand that two transactions do this T1: RecordTransactionCommit() T2: RecordTransactionCommit() T2: ProcArrayEndTransaction() T1: ProcArrayEndTransaction() but I'm failing to imagine this if both transactions are trying to update the same row. For example, if T1 is updating a row that T2 wants to update as well, then T2 has to wait for T1's call of ProcArrayEndTransaction() before it can perform its update, and therefore it (T2) cannot start its commit sequence before T1 has completed it: T1: RecordTransactionCommit() T1: ProcArrayEndTransaction() T2: RecordTransactionCommit() T2: ProcArrayEndTransaction() -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: