Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.
Дата
Msg-id CABOikdOCLDQ0iUnGLRHsy7NKX6iqVdSOWVBBjDv9KKKMf4Ecng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers


On Tue, Feb 7, 2017 at 9:29 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Alvaro Herrera wrote:

>
> Hmm.  Now that I think about it, it is probably possible to have a
> transaction started before CIC that inserted a bunch of rows, and then
> runs the UPDATE during the CIC race window.  Maybe there's a reason the
> bug wouldn't hit in that case but I don't see it, and I'm not able to
> test it right now to verify.

Pavan adds that it's possible to have a transaction do INSERT while CIC
is running, then some other transaction executes the UPDATE.


Just to elaborate on that, once a backend ends up with stale cached bitmaps, AFAICS only a second relcache flush can correct that. This may not come for long time. In fact since CIC is already holding a lock on the table, I think second relcache flush will only happen at the end of phase 2. This can take a long time, especially for very large tables. In meanwhile, the compromised backend can run many transactions with the stale information. Those transactions can see not only the existing rows, but also new rows inserted by other new but now committed-good transactions. 

It's all theory and I haven't had time to try this out.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] Cache Hash Index meta page.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Idea on how to simplify comparing two sets