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

> Tom Lane wrote:
> > Release note updates.
> >
> > Add item for last-minute CREATE INDEX CONCURRENTLY fix.
> Hi,
> Sorry for not noticing earlier, but there is a bug in the notes:
> +      If <command>CREATE INDEX CONCURRENTLY</> was used to build an index
> +      that depends on a column not previously indexed, then rows inserted
> +      or updated by transactions that ran concurrently with
> +      the <command>CREATE INDEX</> command could have received incorrect
> +      index entries.
> CIC bug does not affect inserted rows, only updated rows, since the
> bogus bitmap is only used to compute whether to omit index tuples for
> HOT considerations.

That's correct.

> Also, the bollixed rows do not receive incorrect index entries -- they
> just do not receive any index entry at all.
I think it's somewhat both. While it's true that the updated rows may not
get new index entries as they deserve, they will be reachable from the
older index entries. So while a query such as "SELECT * FROM tab WHERE key
= newval" may not return any result, "SELECT * FROM tab WHERE key = oldval"
may actually return the updated (and wrong) tuple.


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

Reply via email to