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 1ucriC-000OoM-E8 for pgsql-general@arkaria.postgresql.org; Fri, 18 Jul 2025 20:29:44 +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 1ucri8-00GOSZ-Bd for pgsql-general@arkaria.postgresql.org; Fri, 18 Jul 2025 20:29:41 +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 1ucri8-00GORn-0R for pgsql-general@lists.postgresql.org; Fri, 18 Jul 2025 20:29:40 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ucri6-008Vli-0e for pgsql-general@lists.postgresql.org; Fri, 18 Jul 2025 20:29:40 +0000 Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-b3220c39cffso2447577a12.0 for ; Fri, 18 Jul 2025 13:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752870575; x=1753475375; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MSHNSib2u2gdaDt/HPIGyY/gCZ0jcx0eeYlbryfYuHA=; b=SgJJdOo5sc5p5/1R7o10TdMxGmzLyEG08cLSTcX4zH+JvhDn+0vDaH2KRg2t+J7y0S TbOwxYtj7sZ+LBOFUCh6vpWXimzMjkvCVd87I6qHEcvjfNThYf7hTyUW1toHz6/W4mYJ ASYZgut+HPARXv8f4X66KHqeIpYy/noFjuuZglooq2lMPorYiv9/R1hv54CA+MV/NTa7 Jt1O+9a3K3FsB2d5qcRTpRkLbTVbkPfTdc1xu/7oID+WSzgM9rRrKT/DpWDb9Ue6Gw+8 TrTeP44Trtc0mcP0G2mh025b37SsG7VXqvmnz7ITS38U9vWWX3A9Qmsep/abEhNBeDtw twiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752870575; x=1753475375; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MSHNSib2u2gdaDt/HPIGyY/gCZ0jcx0eeYlbryfYuHA=; b=cuMDq90qAzr4sWnf101WTUtcCSD4bbWAKt1kBWInThjYNgf4kfMKjCILMmhwq8njRi JlfaEuAx92WhPwhF0fMHm9qgyqXJGXfotEToVHe29pb68qmjPUlQivgRqNpas2zo3+EF HkcAEFjXPZzBRZvXQlGxLHpzeVQYsLdPxbCVOQUf5HQrDf73BHLA6fQSy7tyswXvSJP5 cXVrvDH9FXvV1pcIid05FwclRIT1Yw9obx+2l/E7+HHYyBcYw8EpPRIjn9kFUlQD/g/+ YCAbAX25PQorADZ1QZUFtLA/ze9MkEa/v+u14lQacGOCGGulI3ehp49D+TS/npdBvq/k pqFQ== X-Gm-Message-State: AOJu0YybBgLvaOVM4AT7+8dJpfDoJZfL9xwsyhPpibr7gRGH2EXFWn4N /PWoSXMsP8sSSe2XaUAJwYmHe8qPtt01wtM+e5retqejwcEaMtlPCXlv1uCZmqpmLJsmhTGhmw6 BEgY9SvdeHx1X6fRsHof4pJxwDd7M/8KomaFV X-Gm-Gg: ASbGncuOG4TmaniGJtOrrOgVN1Ufo2vmef6/KcLcApFm+CVN2ejJlVgW3sojz52B3HS GQaW/6mob2gINXIxPv5izDoQ2f3FYAvBRbni34f/34Wwjr4qtKoJrBEjWtQXzX3lx8CTyUXBLOL KFyLxUsBeTKMJ9KVgzhXfOfNxNt1RLQQHbwc4XECSXvPZlkgTS3NyZpm1uIchZVcaKsgxugxXnc EP8FyEfq0UWbmlVpw5sv2LbSnhJtrXVFBwbBv+4 X-Google-Smtp-Source: AGHT+IEqTzKnx+pQl8hdq9KgBtWTOz13C0WMXZuCO1SQUSuSFzj/HlKAkZvCrTYURuI4zLv3cNDqldqJjt2eC3TWb70= X-Received: by 2002:a17:90b:4cc4:b0:313:f9f6:309f with SMTP id 98e67ed59e1d1-31c9f44dfc3mr15567955a91.34.1752870575350; Fri, 18 Jul 2025 13:29:35 -0700 (PDT) MIME-Version: 1.0 From: Jon Zeppieri Date: Fri, 18 Jul 2025 16:29:24 -0400 X-Gm-Features: Ac12FXwvgsVq8A6_0Dheugl2RkHq3DS2bAKIeNgAXn7swpkZVBfpnGBrkP-LtVs Message-ID: Subject: Possible causes of high_replay lag, given replication settings? To: pgsql-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, I just had a situation where physical replication fell far behind (hours). The write and flush lag times were 0, but replay_lag was high. The replica has hot_standby_feedback on, and both max_standby_streaming_delay and max_standby_archive_delay are set to 30s. What could cause a situation like this? If the network were a problem, I'd expect the other _lag times to be high. So it appears that the replica was getting the WAL but was unable to apply it. Are there situations where the replica cannot apply WAL other than the kinds of conflicts that would be addressed by the _delay settings? I checked pg_stat_database_conflicts, but there was nothing in it -- all zeros. - Jon