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 1uwy4r-009FS7-FX for pgpool-general@arkaria.postgresql.org; Fri, 12 Sep 2025 07:20:13 +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 1uwy4p-00DXWo-P1 for pgpool-general@arkaria.postgresql.org; Fri, 12 Sep 2025 07:20:12 +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 1uwugy-00BibZ-Np for pgpool-general@lists.postgresql.org; Fri, 12 Sep 2025 03:43:21 +0000 Received: from mail-qt1-x82a.google.com ([2607:f8b0:4864:20::82a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uwugx-001xMM-1j for pgpool-general@lists.postgresql.org; Fri, 12 Sep 2025 03:43:20 +0000 Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-4b62805b2a4so17393321cf.1 for ; Thu, 11 Sep 2025 20:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757648598; x=1758253398; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QOBB3/Qk/zx+tCeXGrVCcHJGl/ayFyMoOP8VYzI47VY=; b=NzROJIEnsA/r9Wqgg0AOUy/0ybvNJvGsdrersp/rAJ0LjGHlvdJKVNF4nR0xDsxECk voLi1H2Wz0NZYuXpITDbjQKwG7PqEkV5uxCxwBrKSo5XRgrHyTIcNQedtgW/qeRtELhC zE2epHoYtL3FXbzLseP4TEIgaQiIgdRP7CEQSq88D3n5sGLZo1rpg0/cNiiVdaUk/GFd u2fcuSTq1RHm8dEnMJVMXqztASe7lzwaVmbzgnH1lhClKhshkv00azJX/nmpB7FH20GI hR7v7872gm1OID8i86GRvbYJCrfcdYN9OocVToiZ4sHWyOLVNN8IA0dIGScHJ9EW+QFb 0eUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757648598; x=1758253398; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QOBB3/Qk/zx+tCeXGrVCcHJGl/ayFyMoOP8VYzI47VY=; b=wNiIpVaZsdQ00tRkVxZYhuoGJ76k1JYfChxgbyhc/x6y0WSUruYdLWzLkJ3JHLcZlq zd8nCEeTVLACmJm8+T0WBfDA1bE0t7lI4DkAv/iO4lcrbteBSFWFV81rTFqmt/nXpR+E TPVGbZ1VtV/ifDHNDU8E2qu1v+5dfGyXqCzCwnJ70By7UXs9t9+755SoHzgPMj8E3ihw bbCBu6MFYimrLqoJbuVb1L2GqWWg/1NYcGFNbH9izlPb9/N5PkxR4fNggFtQbQwqb4tk Yu8xTCqbg3m60ethPZgOet8Pkbxpyc5hFpIRExE8ledrk7AQfN8EuWpMWmlpq1jPdMNi BPNQ== X-Gm-Message-State: AOJu0YwtUlN+HvMB07XravRk4qvKRHzn9xwy1QGza20n8DA1TyK+XkfC 6tScM2YUiQckXaRyucILZiVFWdenUa/1ah09ZXnNOl+V4g5fqV7njKbf1IMXJrgWxpEHJ4N/IYP RDkQCHt+2HydldKRgayRiPawSh9JaVorsDA== X-Gm-Gg: ASbGncupo5D+PsR5+GLnqJPzq8YbEmqQ31tiW8MsZEdCWLqos6CE9pvFjxYW3SkjT6u Nigax/HZukjHPubpOTBqFzSSTZR9aPLqpoYnO+dGExncrXVvFtJXT8jcPViC64gNDT8Lxyy7Ehz ol0USuiBCNZRIH84gmB5+9VSik7SPMBFQufVdBTbZZR/veBlLOYPCoVHy0EkwY/1nYAQqlZo9hS vaJCpEPdXTFMb3u+FBGI7AexeGB7mM+s/aT4d3TeQp6/h9STk8= X-Google-Smtp-Source: AGHT+IEeemTlI+xqKZ4kseu1ftlS6aKkq0viuh8d3aqt6mDyZleLYx6WRvZ1IIFimmBXqA+jFE5p4NdCe8g9lqReivo= X-Received: by 2002:a05:622a:114e:b0:4b4:8e6e:51b4 with SMTP id d75a77b69052e-4b77d1b6841mr19633601cf.82.1757648598332; Thu, 11 Sep 2025 20:43:18 -0700 (PDT) MIME-Version: 1.0 From: Macao Tom Date: Fri, 12 Sep 2025 11:43:07 +0800 X-Gm-Features: Ac12FXyFsYsgV37O179DKjQ7Nq2rV_P92Uz0RtjlTN5rLKzcDhTg8QSpg1KFscg Message-ID: Subject: About pgpool failover / switchover To: pgpool-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000057f988063e927475" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000057f988063e927475 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear pgpool, I built up a postgresql 17.6.2 3 nodes cluster with 3 pgpool 4.6.2 , when I try to switch over using =E2=80=9Cpcp_promote_start -s =E2=80=A6..=E2=80=9D= it seems other standy nodes can not follow the new primary node. However, after I remove the =E2=80=9Cpostgres.auto.conf=E2=80=9D in each server and switch over using t= he same command again, it works. I have also check what store in =E2=80=9Cpostgres.auto.con= f=E2=80=9D, it may store many config like =E2=80=9Cprimary_conn_info=E2=80=9D which connec= t to the old primary. Do you have any idea about this? Or do you know what mechanism cause postgres store the old primary info in =E2=80=9Cpostgres.auto.config=E2=80= =9D file? Best regards, Terence --00000000000057f988063e927475 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear pgpool,

I built up a post= gresql 17.6.2 3 nodes cluster with 3 pgpool 4.6.2 , when I try to switch ov= er using =E2=80=9Cpcp_promote_start -s =E2=80=A6..=E2=80=9D it seems other = standy nodes can not follow the new primary node. However, after I remove t= he =E2=80=9Cpostgres.auto.conf=E2=80=9D in each server and switch over usin= g the same command again, it works. I have also check what store in =E2=80= =9Cpostgres.auto.conf=E2=80=9D, it may store many config like =E2=80=9Cprim= ary_conn_info=E2=80=9D which connect to the old primary.

Do you have any idea about this? Or do you= know what mechanism cause postgres store the old primary info in =E2=80=9C= postgres.auto.config=E2=80=9D file?

Best regards,
Terence
--00000000000057f988063e927475--