On Tue, Feb 7, 2017 at 9:29 PM, Alvaro Herrera <alvhe...@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
