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 1vEPyt-00BSE3-7P for pgpool-general@arkaria.postgresql.org; Thu, 30 Oct 2025 10:34:10 +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 1vEPyr-007Wou-AR for pgpool-general@arkaria.postgresql.org; Thu, 30 Oct 2025 10:34:08 +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 1vEPyr-007Wom-4s for pgpool-general@lists.postgresql.org; Thu, 30 Oct 2025 10:34:08 +0000 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vEPyn-0053FW-31 for pgpool-general@lists.postgresql.org; Thu, 30 Oct 2025 10:34:07 +0000 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-3c8fb195c23so649455fac.1 for ; Thu, 30 Oct 2025 03:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761820444; x=1762425244; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=gd7lnljJ8jBVkWKwbI5lKrkwTa+8tTR27TMb+ZPFcf4=; b=TodFpAvgB3qhSBJYmYFwCsLHQ2AtxYkJ04503VronIJCK1tZ15wqTY604gKg5KJrIE qzgp7YE3i4mjP3KgNlHkBXCWqtw6Ue4YCT29btMJ/T7Z7E4QHW6JmFNZebmelA+N3szU y6UeAUjin73iz7L3uN3Tq4uidlQeGZUXRlabxM4KcbnUN4FF8J1oYUvc5KskpFO01d6N hHmotgRkfvqzUyW/1qdQUdJeZIU4wNQQAwy9jrzpMprfxUj2EmhaaiLldzsMUphdt54F q/8pWpxJN7AeEBEMMZkyNSCSni1Ykrf7ZRnwVLr0vJ9nRSk8AEv+HY/KkXwrvAUdPPXH YxdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761820444; x=1762425244; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gd7lnljJ8jBVkWKwbI5lKrkwTa+8tTR27TMb+ZPFcf4=; b=rn7ehQU5rRfyZReDSxDTidGi4GxEgKFYj+IqYOHcdWInoVVfpcJoQmURXgbIkGVOtb O/YGq7hMoB7BZtO17bQEn+pjzlona81UNlRlHrQ483EMkfRd+IzjxeXXBObl9fZzpdfA HryqPANkkfXfLMyS8nggIfo5BpMUXzmfr91qXk2mDSJ3VQUYeXvVNAB8kfJW0REHc3FJ rYOoTInqI6b5u7rBv5rDLp7fpv0m3W9jDpXErHkUgXw57g8anM4prw4FgxVlJE2hkJji m8V3B+dgprCXlYymKLE9PmBwau2h0RbiL2taJHZd6JXqCEiEgX/nhMF66GaSfA63wZ8J LIoA== X-Gm-Message-State: AOJu0YxPIB+isOpn6Pdbjzun4cvWPE2YTWjGuR4XwmOmW+Zv9YkMnWAq EfrjkvRdGxLfUMM3DTyiKADCUkSBySU2Tko91M1BsVeHvDGeDx3gXpABZrapwoV0ZYGHqGHXAb2 xVdaTbGw6rxRBqKgqJbIboxqx94UoeJ/BUx1Y X-Gm-Gg: ASbGncvqlocwdTeQsou2WS0JDisMiV2VnVHwd9fYu+m2kNyCZt7fLrEhfreVFAWYEUP lt7HctnnCvi5Or8R2XiSxxSlUfhElKTfqruCLvf8KI9H9WyRc8ExhHgOV5xmnMxFZiOmzu5PtmL 6jM6cRf7z5dd2JP1udauM4eg15F4KW3ysYogjo0byGgymOl9lgUrLWeCgTMo8qMKEYPEDzVEL/W 6jjpd5l4NQUn1+dZm0yIT34vhcERI3K6Uh36aleE3CaX5iUo1/1kOmzgYk= X-Google-Smtp-Source: AGHT+IE8K/YHNxRZCrKtZHqo/OX902VrkNSnyX25N+hbEKYSubsQ4gqBbSEGossTDG9p1BCfQHmGBfLYq76WL/9qwh0= X-Received: by 2002:a05:6871:2e88:b0:340:5682:7219 with SMTP id 586e51a60fabf-3d746f07555mr2954770fac.27.1761820443967; Thu, 30 Oct 2025 03:34:03 -0700 (PDT) MIME-Version: 1.0 From: Luca Ferrari Date: Thu, 30 Oct 2025 11:33:27 +0100 X-Gm-Features: AWmQ_bkZypvTOtA1wU4nl77RnxJd-YP3KP7Nb_xxMfS0oCvueuJsSZcTdSuGf9c Message-ID: Subject: rebooting a standby causes it go down on pgpool side To: pgpool-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi all, I've three identical machines, running pgpool 4.6.2, postgres 17, one primary (pg1) and two standby pg2 and pg3. The initial situation is: % ssh pg1 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:01:05 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:01:05 pg3 5432 1 0.500000 waiting up standby standby 0 streaming async 2025-10-30 11:01:05 % ssh pg2 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:01:10 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:01:10 pg3 5432 1 0.500000 waiting up standby standby 0 streaming async 2025-10-30 11:01:10 % ssh pg3 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:01:10 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:01:10 pg3 5432 1 0.500000 waiting up standby standby 0 streaming async 2025-10-30 11:01:10 I don't know why, the machines are reported as "waiting up" even if eveything is working fine and I've waited several minutes without having any change in the status. Now, if I reboot a standby, let's say node 3, it comes up with a "down up" status and the only mode I've to make pgpool see the node as healthy again is to run pcp_attach_node. % ssh pg3 'sudo reboot' % ssh pg1 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:01:05 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:01:05 pg3 5432 3 0.500000 down up standby standby 0 streaming async 2025-10-30 11:08:21 % ssh pg2 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:01:10 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:01:10 pg3 5432 3 0.500000 down up standby standby 0 streaming async 2025-10-30 11:08:21 % ssh pg3 'sudo -u postgres pcp_node_info -U pgpool' pg1 5432 1 0.166667 waiting up primary primary 0 none none 2025-10-30 11:09:08 pg2 5432 1 0.333333 waiting up standby standby 0 streaming async 2025-10-30 11:09:08 pg3 5432 3 0.500000 down up standby standby 0 streaming async 2025-10-30 11:09:08 Is this normal? Because the node is streaming regularly, so it is fine on the postgres side and it should also take over its last status at boot (i.e, at least waiting). Anything I should dig for? Thanks, Luca