Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Release note updates. |
Дата | |
Msg-id | 20170207152309.szeiqnprt2kzij66@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Release note updates. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Release note updates.
Re: [HACKERS] [COMMITTERS] pgsql: Release note updates. |
Список | pgsql-hackers |
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. > (I fear this is too late for the current set of releases; I don't want > to make the packagers redo their work just for this. But we can correct > it for future wraps.) I think a large fraction of the readers will grab the release notes from the website anyway, not their local copies. And the "press release" is a source that will get to a large number of readers too. I think it's fine not to re-wrap. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: