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 1tYptR-00FkD0-Ps for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 17:12:26 +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 1tYptP-002QxX-4I for pgsql-general@arkaria.postgresql.org; Fri, 17 Jan 2025 17:12:23 +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 1tYptO-002QuL-Lq for pgsql-general@lists.postgresql.org; Fri, 17 Jan 2025 17:12:23 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tYptM-0003Q0-1t for pgsql-general@lists.postgresql.org; Fri, 17 Jan 2025 17:12:22 +0000 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5db6890b64eso3846581a12.3 for ; Fri, 17 Jan 2025 09:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737133939; x=1737738739; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XBIpgJfD1n9Oy9NkNvgXLAsGb9PiYhakD26DtqsLVsk=; b=SL7EnwT1bUf5GPO6uJ6qCW9SEddA23z3RHlxbfjQlldw3FTx0ZYId12cy04IFSOWzN pHR7cjqn/bPceLs53JZjfCsVNIACOfcDCv2hM+kVfSFEIF6c0MzUbKsK2QbS8QXueksf FvB6G5sM3qJiUUWJGtJkZE8xQIg/jCUFV4Ff0sfZd0PYHxwkzfyU4xL/8cT47dejT2eA Z84AYJA2SKLHXivnjczcp0KrR48bzWYePyxSNKgkQj+xECCkJwJkPNGZzrEdXgJiWbSF MCoqmH1IMPV7sxYBv+PyGT/li+G629h2arTt9X8J6+Bavy5FDkSCXT1pPKoRYO1uKQgH aJ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737133939; x=1737738739; h=cc: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=XBIpgJfD1n9Oy9NkNvgXLAsGb9PiYhakD26DtqsLVsk=; b=EMcc7P0GjrYC8r4P4AaRol8wCEa20zuGfOsCbSOa/v8fiT4Fx4iEhm9JygRlJfFzpZ o5CshxkoENzkobS1+yXZB/zjSEZiPHd34sA3rhL35busS5KRi6czDeR9wCeRO8cLfmV7 j3wUQMX8+/B6a6ZR9sJwco6qLtpD82pRaIbPvZ+LJSZa7W6sSH78VMW9rYMmVcOteCg/ 01CwaN1qn1r596oKQrGo3luegH+1jg650UqNGKfJTOT3qbsw6HM2u70c/n+xg+2C3NKg IwpVmm6LBQ0vZkq86cJd/2/SfgnKq1WFpOmH+ZyFB1EEpescvUfME+aMSvF71BTXzx0c pqkw== X-Gm-Message-State: AOJu0Yx3gR4oiDY2yjYltbBbEfYSLarck9weKG0SuuXdo8XiX2XnZ9qc kWzHY3bG/6tXeINGr/YevWmCl7zO36fSoVRAp/m56iKorohCNJPAF+Fy95PCcdL5+0B5rQJnSbb sdCJqd9kMwPPyCsOKI6vbEgpe8zw= X-Gm-Gg: ASbGncvFSO5XV3vMpSx+/yfhkGUSb6qJpu1cNSqOViqIUnMKrqqcS31g5dTSbSHIBqx 5Gi+cmaBIaSn2GQnESBr+dYT0Hf7GzEMaUipR X-Google-Smtp-Source: AGHT+IG13zDu3wNGnSz1dWBE/FXnPrq1BhJcQ1JNxTFrwLD9n6keEohe7j+Y37j4UnRT/m2AxnoT4zA1rL5eawD25YM= X-Received: by 2002:a17:907:7e95:b0:aa6:715a:75b5 with SMTP id a640c23a62f3a-ab38b44d44fmr318757466b.46.1737133938980; Fri, 17 Jan 2025 09:12:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Franjo Stipanovic Date: Fri, 17 Jan 2025 18:12:07 +0100 X-Gm-Features: AbW1kvY62gmjwTsB6_KaXrVLacq-4VJKCl_uii_XGW0FagQ6qygJYbEEmH7KIM0 Message-ID: Subject: Re: Different Autovacuum Settings on Master and Replica in Streaming Replication To: Guillaume Lelarge , Tom Lane Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000005c47dc062bea0388" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005c47dc062bea0388 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Guillaume, Tom. In that case, querying pg_stat_user_tables on replica for last_vacuum, last_autovacuum, last_analyze, and last_autoanalyze columns makes no sense? Those specific columns are not transferred from the master? The same goes for n_* columns? Currently, on my replica, all those columns are null and 0, while on the master they have a value. Seems like only seq_scan, last_seq_scan, idx_scan, ... are fulfilled. Also, data behind pg_stats (n_distinct, most_common_vals, most_common_freqs, etc) is replicated, right? It seems that we can query those just fine. On Fri, Jan 17, 2025 at 4:34=E2=80=AFPM Guillaume Lelarge wrote: > Hi, > > Le ven. 17 janv. 2025 =C3=A0 15:38, Franjo Stipanovic = a > =C3=A9crit : > >> Question regarding autovacuum settings in a PostgreSQL streaming >> replication setup. Specifically, I am curious about whether it is possib= le >> (and advisable) to have different values for the following settings on t= he >> master and replica databases: >> - autovacuum_vacuum_scale_factor >> - autovacuum_analyze_scale_factor >> >> Can the above settings be configured differently on the master and >> replica databases in a streaming replication setup? I just tested this o= n >> AWS RDS Postgres. >> > > They could but it doesn't matter. VACUUM and ANALYZE aren't executed on > replicas because they are write operations, and you can't write on replic= as. > > >> How would those different settings interact with replication, for >> example, if I apply change on master, would it be replicated to replica = and >> override my replica setting? >> > Changes on the postgresq.conf file aren't replicated, but ALTER TABLE ... > (SET autovacuum...) are. > >> I was expecting that this is not possible in streaming replication, only >> in logical replication. >> > > You're right, it's not possible. > > > -- > Guillaume. > --=20 best wishes, Franjo Stipanovic --0000000000005c47dc062bea0388 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Guillaume, Tom.

In that case= , querying=C2=A0pg_stat_user_tables on replica for last_vacuum, last_autova= cuum, last_analyze, and last_autoanalyze columns makes no sense? Those spec= ific columns=C2=A0are not transferred from the master? The same goes for n_= * columns? Currently, on my replica, all those columns are null and 0, whil= e on the master they have a value. Seems like only seq_scan, last_seq_scan,= idx_scan, ... are fulfilled.

Also, data behind pg= _stats (n_distinct, most_common_vals, most_common_freqs, etc) is replicated= , right? It seems that we can query those just fine.


On Fri, Jan 17, 2025 at 4:34=E2=80=AFPM Guillaume Lelar= ge <guillaume@lelarge.info= > wrote:
Hi,

<= div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 17 janv. 2025 =C3=A0=C2= =A015:38, Franjo Stipanovic <fritzfs@gmail.com> a =C3=A9crit=C2=A0:

Question rega= rding autovacuum settings in a PostgreSQL streaming replication setup. Spec= ifically, I am curious about whether it is possible (and advisable) to have= different values for the following settings on the master and replica data= bases:
-=C2=A0autovacuum_vacuum_scale_factor
- autovacuum_analyze_sca= le_factor

Can the above settings be configured differently on the mas= ter and replica databases in a streaming replication setup? I just tested t= his on AWS RDS Postgres.=C2=A0


Th= ey could but it doesn't matter. VACUUM and ANALYZE aren't executed = on replicas because they are write operations, and you can't write on r= eplicas.
=C2=A0

How would those different settings intera= ct with replication, for example, if I apply change on master, would it be = replicated to replica and override my replica setting?=C2=A0

Changes on the postgresq.conf file aren't replicated, but = ALTER TABLE ... (SET autovacuum...) are.

I was expecting that this is n= ot possible in streaming replication, only in logical replication.


You're right, it's not possible.<= /div>


--
Guillaume.
=


--
best wishes,
Franjo Stipanovic
--0000000000005c47dc062bea0388--