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.96) (envelope-from ) id 1wplaX-001prq-34 for pgsql-docs@arkaria.postgresql.org; Fri, 31 Jul 2026 11:39:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wplaW-00Fqpk-34 for pgsql-docs@arkaria.postgresql.org; Fri, 31 Jul 2026 11:39:40 +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.96) (envelope-from ) id 1wpiyR-00F9bd-21 for pgsql-docs@lists.postgresql.org; Fri, 31 Jul 2026 08:52:11 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wpiyO-00000001EnS-1ftO for pgsql-docs@lists.postgresql.org; Fri, 31 Jul 2026 08:52:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=5DkYNlSC6LACwqqC+6LXqlidWEW10JMbeh5O8FyoAnc=; b=HOX/b8oPtZ5IBeYb5rqcSo6Cyu m5b4Fwc3z85lljK0J/CIyG09BZDezECDE+cL/AHNiDeXMnpJu9kr7zysZrah+HT5fkp0DJEwB1WUs Rn0olOSEFlzdX3CPV464ST1eyNNtkIfCpFkurl3DSzl3SfLewIuPnUyO1/uzdmE3sdZKqd2ldwshQ MMyeBhxd0f8SV8Ml5jnlWryYyRHeP/3NiZEzaCzgFdWEnO8s46429+Mct29JwgroAFT5BaWFT2AJ8 dh2mNSLuN/69OJ5LpTTFIh39524Os/L7Xy078W4eJfVFxEPxHHMVkKuuHtwXRpeh0fBQ2dFaKc9ZK OcbzH1OA==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wpiyM-003lhe-0t for pgsql-docs@lists.postgresql.org; Fri, 31 Jul 2026 08:52:06 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1wpiyK-00000009Ce0-2l14 for pgsql-docs@lists.postgresql.org; Fri, 31 Jul 2026 08:52:04 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Delayed replication missing in documentation To: pgsql-docs@lists.postgresql.org From: PG Doc comments form Cc: oli.sennhauser@fromdual.com Reply-To: oli.sennhauser@fromdual.com, pgsql-docs@lists.postgresql.org Date: Fri, 31 Jul 2026 08:51:15 +0000 Message-ID: <178548787563.1228.7091256507204447634@wrigleys.postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/18/warm-standby.html Description: Somewhere here: https://www.postgresql.org/docs/current/warm-standby.html I would expect a few lines about the possibility of delayed replication/delayed standby. After going through all this site I finally ended up googling and found this: https://about.gitlab.com/blog/delayed-replication-for-disaster-recovery-wit= h-postgresql/ So, yes PostgreSQL can do delayed replication. But it is hidden here: https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC= -RECOVERY-MIN-APPLY-DELAY What about adding something like: 26.2.10. Delayed Replication When streaming replication is used a standby tries to keep up as fast as possible. But sometime it is desirable for a standby to lag artificially. The most common use case is to not apply Oops-Queries or to not provide the most recent data to a specific user group (freemium business model). This can be achieved with the the configuration: recovery_min_apply_delay =3D '4h'