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 1vE1Sj-003L6q-KN for pgpool-general@arkaria.postgresql.org; Wed, 29 Oct 2025 08:23:20 +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 1vE1Sh-00GwI9-Vr for pgpool-general@arkaria.postgresql.org; Wed, 29 Oct 2025 08:23:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vE1Sh-00GwI1-KR for pgpool-general@lists.postgresql.org; Wed, 29 Oct 2025 08:23:18 +0000 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vE1Se-004LY5-2M for pgpool-general@lists.postgresql.org; Wed, 29 Oct 2025 08:23:17 +0000 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-3c73e93eadfso2458542fac.3 for ; Wed, 29 Oct 2025 01:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761726196; x=1762330996; darn=lists.postgresql.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=z/81kRGzAowAtIdgJ8nJpqZ46oSpku6gGvdfg8CNDpA=; b=D2rskIj4t4ybNl8O0mjMLX2hBvRBRSfJ2xrcdyst5krTuoHkIBYQR4dAhnRKb6BdYR 3eOaKl4bEIYwSaqQsnfZBByx8pw1O0akxCHm2AYcw7YdcD8jJIV31TuRVwzltFUUY75a GoTrUQa+2A6/4tJk1Lu7IwIm2ItL0fGAu8oNuIm0Ug1SRbaiShp4eAs3VJE0uzm5RkgV EQUETFeIpQMec1ZatzG/4O5WG1tmmpmHdoBUW4woP8sbNUA43zsdPtkYLO1CLNrOumNH CnxSC+1d6FHgsGy1XMfPok6YBoFaWMWuhuntkg6+Qp1ehaUydXF8xyTVD8AC4wDyvZqm yLTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761726196; x=1762330996; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=z/81kRGzAowAtIdgJ8nJpqZ46oSpku6gGvdfg8CNDpA=; b=GPaxr61b++258KcasF1Pyvtuh6culhnDPwduZ/sUbMbn/AaMlLq3iPSNUwEB9FBL/B fYnLd9DZz+vuATBXv9zxdgpZl4+WEIHE7GwTdXvBhzu7vBwy5WNW9sdd6ep3ZJjtg404 b3NNUGlzXegNsPtlKXNFySJD/GoJjQsllgpSG8fdhRCXOTjsMJppaJh1/GtUsU80djkn j8s68J/LDobVGl84ULdT8RgWXLp2JfSDa7ooJszoBb3r5arO4Ptfvf2HtjqXe62Vjm8B T8YJD44pEM3Uilam2OQgeyKrGkLqxw9u5K99/d9q/Nte1qODeJcpibt4EjkazguMhVZ/ IWSA== X-Gm-Message-State: AOJu0YxDd3zrqxlNcZUEknKq1O3YbF87sy4Ai0Vb3QA1AcX9JCaVD9Sw 5L/LmpY9n9eGpQ27OCgEDtnXGe6CyEL7scd4xlJhydJQDkFF6v6aJr66B7OjiATqzucg4rhdBis pudYACDFlz3AHLgfqeey+KjbDMnHsmiEJioP9 X-Gm-Gg: ASbGncubQ+B552LNcV68Zw2TUCFJhapgutTl3Q3E+BBDHjmujcw6Uolsz62UMmduk+4 7Wx0XseAGbPIcLgigWmp4mBd4XZtKtepRSZYsQfEOt4vrA5TjAjUWd53dbqsYJQn+vGqQu3cvSs S3zr+jR4XWYFxy5EZD3xYDtH1o23m6f/3+C3/JR66lMfqOYNMTC1jAjkketaZWqvgDFPTGgg3Hu t54GEU7bYrRsuSgy5zFzGxxhmWn6GAO14XlkbggE2ICp2kd9JRWY0rlK4g= X-Google-Smtp-Source: AGHT+IF8GezvT/8u1MF9f6zz0kVEPrdhP6ktBb6YFSl5WFg9r0UeyGtiOFBucTW2rffgDJbuFtIr3XnARmA3YhV9n6o= X-Received: by 2002:a05:6870:c351:b0:3cd:6ca3:da05 with SMTP id 586e51a60fabf-3d747f6c6c0mr1056182fac.45.1761726195580; Wed, 29 Oct 2025 01:23:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luca Ferrari Date: Wed, 29 Oct 2025 09:22:39 +0100 X-Gm-Features: AWmQ_bn_MtUGPa8ArAyMFfrkaqgSV2GXSzyDIC3H_E4TUMeuwllKFcF3ZvviwCc Message-ID: Subject: Re: what is causing different pcp_node_info status To: pgpool-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Oct 23, 2025 at 8:04=E2=80=AFAM Luca Ferrari = wrote: > > I am still observing the issue, the best situation I come is all nodes > reported as "up up" when queryed on pg1 (primary) and "waiting up" > when queried from pg2 and pg3. > could it be network latency or a similar issue? As explained clearly here the information about the nodes is collected and kept in shared memory. Is there any chance the same process is applied to the pgpool node status? I observed that even a machine reboot does not seem to make pgpool report a status better than "waiting up", evne after minutes, and while replicas are streaming. Restarting then the pgpool service brings the status "up up", this makes me think there is something blocking or delaying pgpool to collect data, and when the service is restarted the node is forced to "dig" the other node status. Something I could investigate on?