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

> 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.


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

Reply via email to