Re: BUG #15074: psql client never returns when creating index (long running operation)

From: Lars Vonk <lars(dot)vonk(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15074: psql client never returns when creating index (long running operation)
Date: 2018-02-20 17:52:35
Message-ID: CAMX1ThhM_5tsAS7JFdpj3Dw_F6SR3-MXFJwUk0Xmh3WXbP7HFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

Thanks for replying. I will double check the network settings, but couldn't
find anything.

Are there any psql / postgres settings I can check, I couldn't find any
that might be affecting this.

Lars

Op ma 19 feb. 2018 om 13:27 schreef Andrew Gierth <
andrew(at)tao11(dot)riddles(dot)org(dot)uk>:

> >>>>> "PG" == PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>
> PG> When creating an index on a table containing approx. 100M records
> PG> the psql client never returns when the index is eventually created
> PG> on the server. This happens both in a psql client (9.6.6) on mac
> PG> osx and using the libpq client via the ruby pg gem when using
> PG> active records migrations.
>
> PG> When running the command directly op the postgres database server
> PG> using the psql client it works as expected.
>
> PG> The logs from the server:
> PG> 2018-02-16 16:11:05 CET:82.161.205.254(59584):REDACTED(at)REDACTED_DB
> :[23141]:
> PG> LOG: duration: 999618.165 ms
> PG> 2018-02-16 16:11:05 CET:82.161.205.254(59584):REDACTED(at)REDACTED_DB
> :[23141]:
> PG> LOG: could not receive data from client: Connection reset by peer
>
> This looks like a network issue; most likely you have a NAT or stateful
> firewall in between the client and server which is dropping idle
> connections, with a timeout set shorter than your keepalive interval on
> either client or server.
>
> The server gets "connection reset" because it tried to send the result
> of the statement, plus the "ready for query" message, and the
> NAT/firewall sent back a reset because it no longer recognized the
> connection as valid. The psql client itself continues to wait for input
> (and will do so until the keepalive timeout is reached if keepalive is
> enabled, otherwise indefinitely) because the NAT/firewall doesn't
> typically send any proactive reset messages.
>
> --
> Andrew (irc:RhodiumToad)
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2018-02-20 17:53:26 Re: Segmentation Fault in logical decoding get/peek API
Previous Message Tom Lane 2018-02-20 16:39:20 Re: pg_dump sometimes misses sequence parameters