Re: Adding REPACK [concurrently]
| От | Mihail Nikalayeu |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | CADzfLwUVQw+XLwurjHYBHuNdDw3mBUUM7fXxaruMt25YB6xbyQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Adding REPACK [concurrently] (Mihail Nikalayeu <mihailnikalayeu@gmail.com>) |
| Список | pgsql-hackers |
> > I'm not sure it's acceptable to cause other sessions to raise errors if
> > they query the table being repacked (or a table repacked recently).
> > That sounds extremely unpleasant. Imagine a long-running transactions
> > that runs enormous queries for many hours or even days, being killed
> > near the end because some DBA decided to run REPACK on a table.
> > they query the table being repacked (or a table repacked recently).
> > That sounds extremely unpleasant. Imagine a long-running transactions
> > that runs enormous queries for many hours or even days, being killed
> > near the end because some DBA decided to run REPACK on a table.
> It will not. It raises an error only for the case table will be "empty" because REPACK switched to new with all tuples with REPACK xid and our transaction treats that xid as running.
> So, there is no regression here, it just changes from "see an empty table because of MVCC violation" to "get error" in the exact situation.
> I prefer the second.
But I agree that a MVCC-safe solution is better. But to receive the error you need to be really unlucky (subtle race - in *first* access to a repacked table in transaction you need to get a statement snapshot in the moment of table swap) or use non READ-COMMITED isolation method.
So, we prevent silent READ of MVCC-violated data - I think it is enough, at least for start.
Mikhail.
В списке pgsql-hackers по дате отправления: