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 1sFOoP-001vTs-V3 for pgsql-general@arkaria.postgresql.org; Fri, 07 Jun 2024 01:54:38 +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 1sFOoM-0069c4-Nn for pgsql-general@arkaria.postgresql.org; Fri, 07 Jun 2024 01:54:35 +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 1sFOoM-0069bH-AV for pgsql-general@lists.postgresql.org; Fri, 07 Jun 2024 01:54:35 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sFOoK-0005Oc-Ed for pgsql-general@postgresql.org; Fri, 07 Jun 2024 01:54:33 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-24c9f297524so868541fac.0 for ; Thu, 06 Jun 2024 18:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717725271; x=1718330071; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=gx80Hb7GzyFl0O8zjHSFq57h1C4y4pPD08owX4q5ftw=; b=I5Ip+TdOFJn7EIoTJx8fkWo3t1DBZJLhnQPJYvwEE/ybP0Z0tRgbBZjzzJhQEXyemw fHyqQR+2vQpogOPn1EdG5v+t1nSBtTGfZi6UTUngJFr7JO7VKi5LfSYEiOqWjZdu56jX rSS75a5HIZTX8FRWO+CtX7BNvPApvzYc2Aml2D95kyModYwftamJbFAH8vUE7/u2Y2Uz VNkWiv6YPlX9jjBXQsUqtyWApVRy+2xitrGfOhysBm+1xibf/3pDPdTL5DxP+hTqniCD eDRfFRP1E1EkOaTumcba5bj/SMskpEnGhEJUq0seKLLBYNZCYp/kQoaEDZU7R3hg33t3 BAsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717725271; x=1718330071; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gx80Hb7GzyFl0O8zjHSFq57h1C4y4pPD08owX4q5ftw=; b=UlwxhK7Ra0oT6dnbuxrcNODwwx47fQjZ5C6ixOm6lWoyEhO/utUfuAWOpXcIiCGZqQ q6T8Ro4kp7ks9jsZzlTEgsV3fA3+cpwEc79bckXGPuv4qPi6alt6VnuB9mDjUPVasGNZ Hq5BA9k0cohyCJYs3UNzbiR8bb6kZ8zzymnmrbOoeFuUcHlYVk5zoBb9Yi46F+88q+tJ K+0MK4q9BUSucnMaPmKnbB0xnfvKBrucJuBOygLxkT0iYUPOqELMOLnCwdJsmycnemHV agJsxpxbYyFrKLvR4Nk5is6sGmcAM5uYX0Nzd+V8cI+b7BR8H3uaiUL2lAGWjHiF+Iyz rdtg== X-Gm-Message-State: AOJu0YwjRNYZRho7uQIG2UsqbcCkrNRFoyklJ3UTJZ8dQRUlW48tXoX3 onYeEWNcaEg/U7NrsIpeGTut05hYJSemkmcnfAxiQvSOOMaGICd/78yIFo6tALKBcpFX5TuqAHF BiXL8yKZ4T2pe3TYNfAyhyxD3qA/cSzHT X-Google-Smtp-Source: AGHT+IGe/1NOyRbMXWJnfrSE18MkW+LRhP5un+tXauJfYugLSsflVKyFRqQeLMzRT+sb/cG/89AVkZSnUlNi+lMn02w= X-Received: by 2002:a05:6870:4151:b0:24c:a414:712b with SMTP id 586e51a60fabf-254644503famr1267249fac.7.1717725271577; Thu, 06 Jun 2024 18:54:31 -0700 (PDT) MIME-Version: 1.0 From: Ron Johnson Date: Thu, 6 Jun 2024 21:54:20 -0400 Message-ID: Subject: PG 14 pg_basebackup accepts --compress=server-zst option To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000a25ab2061a4314d7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a25ab2061a4314d7 Content-Type: text/plain; charset="UTF-8" https://www.postgresql.org/docs/14/app-pgbasebackup.html doesn't mention "--compress=[{client|server}-]method". That first appears in the v15 docs. And yet pg_basebackup doesn't complain about an invalid option. (Technically, this is a bug; I first noticed it a week after copying a script from a PG 15 server to five PG 14 servers, and running it quite a few times without fail.) $ pg_basebackup \ > --pgdata=$PGDATA \ > --dbname=service=basebackup \ > --verbose --progress \ > --checkpoint=fast \ > --write-recovery-conf \ > --wal-method=stream \ > --create-slot --slot=pgstandby1 \ > --compress=server-zst ; echo $? pg_basebackup: initiating base backup, waiting for checkpoint to complete pg_basebackup: checkpoint completed pg_basebackup: write-ahead log start point: 256/BC000028 on timeline 1 pg_basebackup: starting background WAL receiver pg_basebackup: created replication slot "pgstandby1" 42567083/42567083 kB (100%), 1/1 tablespace pg_basebackup: write-ahead log end point: 256/BC000138 pg_basebackup: waiting for background process to finish streaming ... pg_basebackup: syncing data to disk ... pg_basebackup: renaming backup_manifest.tmp to backup_manifest pg_basebackup: base backup completed 0 --000000000000a25ab2061a4314d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

https://www.postgresql.org/docs/14/app-pgbas= ebackup.html doesn't mention "--compress=3D[{client|server}-]m= ethod".=C2=A0 That first appears in the v15 docs.

And yet pg_basebackup doesn't complain about an invalid option= .=C2=A0 (Technically, this is a bug; I first noticed it a week after copyin= g a script from a PG 15 server to five PG 14 servers, and running it quite = a few times without fail.)

$ pg_base= backup \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --pgdata=3D$PGDA= TA \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --dbname=3Dservice= =3Dbasebackup \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --verbose= --progress \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --checkpoin= t=3Dfast \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --write-recove= ry-conf \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --wal-method=3D= stream \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --create-slot --= slot=3Dpgstandby1 \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --com= press=3Dserver-zst ; echo $?
pg_basebackup: initiating base backup, wait= ing for checkpoint to complete
pg_basebackup: checkpoint completed
pg= _basebackup: write-ahead log start point: 256/BC000028 on timeline 1
pg_= basebackup: starting background WAL receiver
pg_basebackup: created repl= ication slot "pgstandby1"
42567083/42567083 kB (100%), 1/1 tab= lespace=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pg_basebackup: write-ahead lo= g end point: 256/BC000138
pg_basebackup: waiting for background process = to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_ba= sebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup:= base backup completed
0


--000000000000a25ab2061a4314d7--