Thread: PG 14 pg_basebackup accepts --compress=server-zst option

PG 14 pg_basebackup accepts --compress=server-zst option

From

Ron Johnson

Date:

07 June, 04:54:20

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

Re: PG 14 pg_basebackup accepts --compress=server-zst option

From

Kashif Zeeshan

Date:

07 June, 07:27:07

On Fri, Jun 7, 2024 at 6:54 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:

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.)

If the support is removed then it should be mentioned in the official documentation.

Regards

Kashif Zeeshan

Bitnine Global

$ 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

Re: PG 14 pg_basebackup accepts --compress=server-zst option

From

"David G. Johnston"

Date:

07 June, 07:32:09

On Thursday, June 6, 2024, Kashif Zeeshan <kashi.zeeshan@gmail.com> wrote:

Hi

On Fri, Jun 7, 2024 at 6:54 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:

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.)

Seems a bit suspect, but as your script doesn’t mention tar the option itself is apparently ignored, I guess silently. Assuming this isn’t an actual regression in behavior in a patch-released older version I don’t see us adding an error message at this point.

If the support is removed then it should be mentioned in the official documentation.

Support wasn’t removed. Re-read the email and check the version/times being mentioned again.

David J.

Re: PG 14 pg_basebackup accepts --compress=server-zst option

From

Ron Johnson

Date:

07 June, 15:04:33

On Fri, Jun 7, 2024 at 12:32 AM David G. Johnston <david.g.johnston@gmail.com> wrote:

On Thursday, June 6, 2024, Kashif Zeeshan <kashi.zeeshan@gmail.com> wrote:
Hi

On Fri, Jun 7, 2024 at 6:54 AM Ron Johnson <ronljohnsonjr@gmail.com> wrote:

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.)

Seems a bit suspect, but as your script doesn’t mention tar the option itself is apparently ignored, I guess silently.

Does this mean that "--compress=server-zst" is only relevant with --format=tar?

Assuming this isn’t an actual regression in behavior in a patch-released older version

My apologies for not mentioning the version: 14.12-1PGDG-rhel8.

I don’t see us adding an error message at this point.

Me neither. It just seemed odd.

Re: PG 14 pg_basebackup accepts --compress=server-zst option

From

Tom Lane

Date:

07 June, 18:33:08

Ron Johnson <ronljohnsonjr@gmail.com> writes:
> On Fri, Jun 7, 2024 at 12:32 AM David G. Johnston <
> david.g.johnston@gmail.com> wrote:
>> I don’t see us adding an error message at this point.

> Me neither.  It just seemed odd.

v14 thinks the argument of --compress must be an integer, and doesn't
really bother with any syntax error checks:

            case 'Z':
                compresslevel = atoi(optarg);
                if (compresslevel < 0 || compresslevel > 9)
                {
                    pg_log_error("invalid compression level \"%s\"", optarg);
                    exit(1);
                }
                break;

In your example, atoi() will return zero and it will sail along with
no compression.  Releases 15 and up have more complex ideas of what
--compress can specify, and seem to syntax-check it much more
thoroughly.

This is a pretty common coding pattern, so I can't get excited
about changing it, especially not in long-stable branches.

            regards, tom lane