Hi Michael,
Thanks for replying. We waited as least as long as it took to create the index. It is reproducible when creating this particular index. To be clear, the index was created, the client just did not get notified.
> How is defined your schema?
What schema are you referring to?
> It could be possible that a CHECK_FOR_INTERRUPTS() added in the code paths where the type of the
index you are creating is involved could help in making the system more
responsive to cancel requests.
I am not sure I understand what this means? It is just psql that we are using connecting to a remote database.
On Mon, Feb 19, 2018 at 08:26:48AM +0000, PG Bug reporting form wrote:
> When creating an index on a table containing approx. 100M records the psql
> client never returns when the index is eventually created on the server.
> This happens both in a psql client (9.6.6) on mac osx and using the libpq
> client via the ruby pg gem when using active records migrations.
Are you sure that the process got stuck? Perhaps it was spending a lot
of time processing and you did not wait for it to finish.
> When running the command directly op the postgres database server using the
> psql client it works as expected.
>
> The logs from the server:
> 2018-02-16 16:11:05 CET:82.161.205.254(59584):REDACTED@REDACTED_DB:[23141]:
> LOG: duration: 999618.165 ms
> 2018-02-16 16:11:05 CET:82.161.205.254(59584):REDACTED@REDACTED_DB:[23141]:
> LOG: could not receive data from client: Connection reset by peer
>
> The psql client just hangs, when trying to cancel the query client side
> (ctrl-c) the server logs says:
> 2018-02-16 16:13:53 CET:82.161.205.254(59961):[unknown]@[unknown]:[25738]:
> LOG: PID 23141 in cancel request did not match any process
How is defined your schema? It could be possible that a
CHECK_FOR_INTERRUPTS() added in the code paths where the type of the
index you are creating is involved could help in making the system more
responsive to cancel requests.
--
Michael
