Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Release note updates. |
Дата | |
Msg-id | 20170207155931.vgzv5umuyfvp4bqz@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Release note updates. (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > Tom Lane wrote: > > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > > > May I suggest > > > > > + If <command>CREATE INDEX CONCURRENTLY</> was used to build an index > > > + that depends on a column not previously indexed, then rows > > > + updated by transactions that ran concurrently with > > > + the <command>CREATE INDEX</> command could have missed receiving > > > + index entries. > > > > Can we say "pre-existing rows that were updated by...", or is that > > too optimistic? > > 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. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: