Re: reindex concurrently and two toast indexes
| От | Julien Rouhaud |
|---|---|
| Тема | Re: reindex concurrently and two toast indexes |
| Дата | |
| Msg-id | 20200222150657.GA54846@nol обсуждение исходный текст |
| Ответ на | Re: reindex concurrently and two toast indexes (Julien Rouhaud <rjuju123@gmail.com>) |
| Ответы |
Re: reindex concurrently and two toast indexes
|
| Список | pgsql-hackers |
On Sat, Feb 22, 2020 at 08:09:24AM +0100, Julien Rouhaud wrote: > On Tue, Feb 18, 2020 at 07:39:49AM +0100, Julien Rouhaud wrote: > > On Tue, Feb 18, 2020 at 7:19 AM Michael Paquier <michael@paquier.xyz> wrote: > > > > > > On Tue, Feb 18, 2020 at 07:06:25AM +0100, Julien Rouhaud wrote: > > > > On Tue, Feb 18, 2020 at 6:30 AM Michael Paquier <michael@paquier.xyz> wrote: > > > >> Hmm. There could be an argument here for skipping invalid toast > > > >> indexes within reindex_index(), because we are sure about having at > > > >> least one valid toast index at anytime, and these are not concerned > > > >> with CIC. > > PFA a patch to fix the problem using this approach. > > I also added isolation tester regression tests. The failure is simulated using > a pg_cancel_backend() on top of pg_stat_activity, using filters on a > specifically set application name and the query text to avoid any unwanted > interaction. I also added a 1s locking delay, to ensure that even slow/CCA > machines can consistently reproduce the failure. Maybe that's not enough, or > maybe testing this scenario is not worth the extra time. Sorry, I just realized that I forgot to commit the last changes before sending the patch, so here's the correct v2.
Вложения
В списке pgsql-hackers по дате отправления: