From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ertan Küçükoğlu <ertan(dot)kucukoglu(at)1nar(dot)com(dot)tr> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: How to prevent "no wait lock" after a connection drop |
Date: | 2018-07-31 22:33:45 |
Message-ID: | 13817.1533076425@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?iso-8859-9?B?RXJ0YW4gS/zn/Gtv8Gx1?= <ertan(dot)kucukoglu(at)1nar(dot)com(dot)tr> writes:
> What I observe during my tests is that if I intentionally drop internet
> connection during any stage of data transfer (that is mostly while inserting
> to tables) application gives error and stop. For next sync operation (which
> runs every 5 mins) gets "no wait lock" error and exit without doing
> anything. That lock stage roughly stays for 1-2 hours or more.
This probably corresponds to the TCP timeout needed for the server's
kernel to decide the connection is lost; until then, the backend session
will just sit there waiting for more data, and it'll be holding whatever
locks it had too.
You could adjust the server's tcp_keepalives_xxx settings to make it
notice the connection drop more quickly.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-08-01 01:48:23 | Re: could not read block 0 in file : read only 0 of 8192 bytes when doing nasty on immutable index function |
Previous Message | Ertan Küçükoğlu | 2018-07-31 22:24:35 | How to prevent "no wait lock" after a connection drop |