Обсуждение: Is CREATE INDEX dependent on the session?
Hi,
Would it warrant a clarification in the documentation:
- Whether CREATE INDEX is aborted if the session is disconnected, assuming it's not in a transaction?
- Ditto for CREATE INDEX CONCURRENTLY?
- Whether CREATE INDEX CONCURRENTLY "returns" immediately or blocks the session until it's created?
Given how these operations may take substantial time, and have no output beyond success, this might be a relevant topic.
On Wed, 2023-09-27 at 11:23 -0400, Ilya Priven wrote: > Would it warrant a clarification in the documentation: > - Whether CREATE INDEX is aborted if the session is disconnected, assuming it's not in a transaction? It is aborted as soon as the server realizes that the client is gone, which may take a while (see the keepalive parameters and "client_connection_check_interval"). > - Ditto for CREATE INDEX CONCURRENTLY? The answer is the same. Note that if CREATE INDEX CONCURRENTLY is interrupted, you are left with an INVALID index that you have to delete later. > - Whether CREATE INDEX CONCURRENTLY "returns" immediately or blocks the session until it's created? It blocks until the index has been created. Do you want to propose a patch? Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Wed, 2023-09-27 at 11:23 -0400, Ilya Priven wrote: >> Would it warrant a clarification in the documentation: >> - Whether CREATE INDEX is aborted if the session is disconnected, assuming it's not in a transaction? > It is aborted as soon as the server realizes that the client is gone, which may > take a while (see the keepalive parameters and "client_connection_check_interval"). Note that unless you change client_connection_check_interval to a nondefault value, the server will not notice that the client is gone until it tries to send or receive data. So a command like CREATE INDEX will typically run to completion even if the client drops the connection. I don't think keepalive settings affect this --- they might cause the kernel to realize that the connection is lost earlier than it otherwise would, but that doesn't result in an automatic kill of the server process. > Do you want to propose a patch? There are enough environmental dependencies involved here that any simple description is likely to contain lies. So I'm hesitant to try to put anything about it into the docs. regards, tom lane