Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9syU-00ChKa-3z for pgsql-admin@arkaria.postgresql.org; Sat, 09 Nov 2024 21:26:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t9syQ-0046n6-TX for pgsql-admin@arkaria.postgresql.org; Sat, 09 Nov 2024 21:26:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9syQ-0046my-Gq for pgsql-admin@lists.postgresql.org; Sat, 09 Nov 2024 21:26:27 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t9syN-0014yF-3W for pgsql-admin@lists.postgresql.org; Sat, 09 Nov 2024 21:26:26 +0000 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-20cf3e36a76so35022005ad.0 for ; Sat, 09 Nov 2024 13:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731187579; x=1731792379; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=AVvWnt1aZwVmHJTiFHCvkx5Tir3ylkx9yfOeVNjwFjw=; b=YDnMI/1pe4GxnoY9mTzNUlrf3yss2gI9EbyJS4xHV9OramD/IaEHxo/F99I3TxHcWc grf0o4xUDHpU+c+liySDm+tgrsTz9bpivoNnahIOhDgC4/HdrOi+T2tg1cgU4qqiUZSS 4Sz2BxFXcgXU6GOyxyrQMvneeRrLzswxdMr0h4KP9Qt2YBX3/709v2Iv6Q07VDw1kVs4 jaXZJs/KuzxMRF6fF/If0a4Kf3baHhVPzD/9NjeDXBFh8KjZIjD0rl6dMJvdWVFOq/5b I6x6VWMEld4O/qMsG07DKuGO0/y7ewso852zlcqFcEx0qh55TdIuZA9lpueHxKeCmBkq Bv8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731187579; x=1731792379; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=AVvWnt1aZwVmHJTiFHCvkx5Tir3ylkx9yfOeVNjwFjw=; b=qMJCR7AcPM2lCPJ6XMS/cIi0CphRd5dfTldCIXArdo7/NQ4Bb7Gq2zqirjJ9aQ/gH0 uF7MSP6hKF/QdlMWnDiINDq523/IuaaBQtuwhcxjN0Tyg6fLHr4KyK2wkWRsvfH5lYsc a894R99mfGlXhVLuDmbvVFagII2geM9FlIa/mLm4JVymvdCug8hMXP7iV3TCJ5HmFh8d 3EyKYXzG2lLLjq7zY4mDRbPNOqObjgiWKhnNfwbUHo8+Mk2k+Jv9IWFLq7Dq6iR8jN0I tY0yUAELSLx0/JABMRmpmsPnbVxD+xfxRrKe+3Lk6cX761to2ExI/jZUz1dL8qtWDKtN manA== X-Gm-Message-State: AOJu0YyXzxcOA+QqJ4ouMbN80RIbq7F2YNTzzpc8JoDrRpQZmY5EHHCW ppvv1tJGNdE3sIo1An/UjY74FUIlqPgafLEnWmYhHHiVlAjuaSuF1sqqZTnAn77wf+i2vZ/d4Lu PwhA7eM0E4S6dgOLNG0C5IejuiYw87jBX+yw= X-Google-Smtp-Source: AGHT+IHlYYOn4pcUTNZlUK+jcm6zOHz7VtNCup9SvGncFTpJLgM32h677qgqhexzPnItr4i129Zy663ZxZWpsk7W518= X-Received: by 2002:a17:90b:38ce:b0:2e2:d15c:1a24 with SMTP id 98e67ed59e1d1-2e9b174113cmr9814445a91.23.1731187578774; Sat, 09 Nov 2024 13:26:18 -0800 (PST) MIME-Version: 1.0 From: Edwin UY Date: Sun, 10 Nov 2024 10:25:42 +1300 Message-ID: Subject: How to check if session is a hung thread/session To: "pgsql-admin@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000ac2c2a0626818454" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ac2c2a0626818454 Content-Type: text/plain; charset="UTF-8" Hi, I am not sure how to explain this, but I believe this is something usually referred to in the JDBC world as a hung thread. This is an Aurora RDS PostgreSQL database that was patched in a supposed to be zero downtime kind of thing. After the patching, I have a user complaining that he has a job that normally gets run in the OS cron session that has been failing. When I check the database, it => SELECT pg_postmaster_start_time(), -> pg_postmaster_start_time() at time zone 'utc' at time zone 'Pacific/Auckland' as "Pacific/Auckland TIMEZONE", -> date_trunc( 'second', current_timestamp - pg_postmaster_start_time() ) as uptime; -[ RECORD 1 ]-------------+------------------------------ pg_postmaster_start_time | 2024-11-06 10:44:51.832663+00 Pacific/Auckland TIMEZONE | 2024-11-05 21:44:51.832663+00 uptime | 3 days 10:29:08 So, in theory it really wasn't zero downtime, not sure Aurora RDS takes care of it but from the output above, it was re-started although pg_stat_activity shows it is still there. Checking pg_stat_activity select pid as process_id, usename as username, datname as database_name, client_addr as client_address, application_name, now() - pg_stat_activity.query_start AS duration, backend_start, backend_start at time zone 'Pacific/Auckland' as backend_start_localtime, state, state_change, state_change at time zone 'Pacific/Auckland' as state_change_localtime from pg_stat_activity where usename = '[blah]' order by username asc I have the output as below: process_id | username | database_name | client_address | application_name | duration | backend_start | backend_start_localtime | state | state_change | state_change_localtime ------------+-----------+---------------+----------------+------------------------+-----------------+-------------------------------+----------------------------+-------+-------------------------------+---------------------------- 31947 | [blah] | [blah] | [blah] | PostgreSQL JDBC Driver | 00:47:21.838892 | 2024-11-06 10:44:53.309388+00 | 2024-11-06 23:44:53.309388 | idle | 2024-11-08 02:00:06.005173+00 | 2024-11-08 15:00:06.005173 (1 row)