Implement a way to build an index without blocking concurrent data modifications

[hvlad]

No description provided.

[AlexPeshkoff]

On 7/25/26 20:30, Vlad Khorsun wrote: * 91ac1e6 <91ac1e6> A way to build an index without blocking concurrent data modifications.

Vlad, there is one main problem with your approach - option CONCURRENTLY silently affects ability to have NOT VALIDATED index instead fatal error for unique indices. I see the following problems: - users often miss warnings, i.e. once upon a time using CONCURRENTLY option they can get active but not validated index and do not know about it - specially taking into an account that new records are forced to be unique; - correct logic with hard job, done for index creation, that should better be not repeated applies to traditional (without option CONCURRENTLY) index creation too, but getting NOT VALIDATED index is not supported in this case. What about adding one more option that controls ability to get not validated index? As far as I can see it's not dependent from concurrent creation and may be used separately.

[hvlad]

Vlad, there is one main problem with your approach - option CONCURRENTLY
silently affects ability to have NOT VALIDATED index instead fatal error
for unique indices. I see the following problems:

• users often miss warnings, i.e. once upon a time using CONCURRENTLY
  option they can get active but not validated index and do not know about
  it - specially taking into an account that new records are forced to be
  unique;

It depends on tool used. We can't control third party tools.
Our isql show warnings, while it is hard to distinguish them from errors.

From the other side: the concurrent index creation is a new feature with a new
syntax and its behaviour re. unique indices is explicitly documented. I.e. if one
uses CONCURRENTLY, it is supposed (s)he read the docs before it ;)

• correct logic with hard job, done for index creation, that should
  better be not repeated applies to traditional (without option
  CONCURRENTLY) index creation too, but getting NOT VALIDATED index is not
  supported in this case.

What about adding one more option that controls ability to get not
validated index? As far as I can see it's not dependent from concurrent
creation and may be used separately.

Good idea, I support it. Could be useful for restore too.

[AlexPeshkoff]

On 7/27/26 14:42, Vlad Khorsun wrote: *hvlad* left a comment (FirebirdSQL/firebird#9106) <#9106 (comment)> Vlad, there is one main problem with your approach - option CONCURRENTLY silently affects ability to have NOT VALIDATED index instead fatal error for unique indices. I see the following problems: * users often miss warnings, i.e. once upon a time using CONCURRENTLY option they can get active but not validated index and do not know about it - specially taking into an account that new records are forced to be unique; It depends on tool used. We can't control third party tools. Our isql show warnings, while it is hard to distinguish them from errors. From the other side: the concurrent index creation is a *new* feature with a *new* syntax and its behaviour re. unique indices is explicitly documented. I.e. if one uses CONCURRENTLY, it is supposed (s)he read the docs before it ;)

Read docs before? May be this happens on the dark side of a moon. :D :D Getting serious - if one can control arrival of not validated index separately from concurrency that becomes much less dangerous. One who wants concurrency will use CONCURRENTLY, if new option is added explicitly - OK, user should be ready to get warning instead error.

* correct logic with hard job, done for index creation, that should better be not repeated applies to traditional (without option CONCURRENTLY) index creation too, but getting NOT VALIDATED index is not supported in this case. What about adding one more option that controls ability to get not validated index? As far as I can see it's not dependent from concurrent creation and may be used separately. Good idea, I support it. Could be useful for restore too.

Certainly it will be useful.