Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDrie-0004hE-17 for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Jul 2022 18:13:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oDric-0005yp-RO for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Jul 2022 18:13:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDric-0005t3-Bm for pgsql-hackers@lists.postgresql.org; Tue, 19 Jul 2022 18:13:14 +0000 Received: from mail-qk1-x72d.google.com ([2607:f8b0:4864:20::72d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oDriZ-0005a4-DV for pgsql-hackers@postgresql.org; Tue, 19 Jul 2022 18:13:13 +0000 Received: by mail-qk1-x72d.google.com with SMTP id k7so8931923qkj.2 for ; Tue, 19 Jul 2022 11:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C0xU/M+K4G9Xi0HFbv3DPlrRG9xOAdepC9rZ2pqSVH8=; b=cWdT6MPDZUrmLjnVXMa7x/xiO+Wr5Z+U6W0V9x09AoNYtyxkcfXvmIfWTWuo1RbGYk PnXpNCMdTY3os35seu9aX7u4G4duQE7jluzqib0U3/2JPuGFN5z0+h5f3WPoLS49YBdp oPiG9HdlzzdE7NBLKsQCAwC6YQejr2aDtdbR7gWeWuMZgXEk+jCZ1ykKM8RvwSqkuWV4 Ev0qqJo+uGlVp7itstC7CLi0rkOBX2WmW2Mb4yh2iz9JD8MyilcL/dgi9WMmHlICr83+ wWORsVdEBDPtUT74B6BTQlVb3ZTLaYIg87QulswV2hxjUPVKXLZ0E1lHg7lxznb7qHi+ 56Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=C0xU/M+K4G9Xi0HFbv3DPlrRG9xOAdepC9rZ2pqSVH8=; b=3GqYRt4ciODlpHMtk14cKf4r9DGDpeR2HzDOP8RKMGk9/5eYqqyTTDXomcN+oDmE0H rMqMegM0wgGriORp9/MfYLrbkp1jB1x7CCNef1n0E7GPY9AnImLe6djGcuNo0F8A1rH5 UypJvtjyvK42ut5yNw3zQ8IzSiIU2GpPj6tPaw5/UBbjbzLSInECA1DbU9w2XA8jUqYc DGahAAFatWkNhLoogoRW8l/6CTiViJ/rxMXkd8PjMLrpZkYNz7qaRTPmhhgSNqkLeNOc 3MX7RdX+28pHVKK8ws2C8JDZ5426s1Qvf8NEUTrVtYxD63i/OxxyA9HVvFjuEfEdn302 Vn2Q== X-Gm-Message-State: AJIora/03QeL7DWlF/Kkrs2xPbQxs2JqYfAWbr6f5dII5qKH1LeRZywi bEgC/BWYvwocGvZZEGiuKQ8qhw== X-Google-Smtp-Source: AGRyM1tYJrW3kXGT1hiROGIsVHCbsrBODhVr6Md5xB1IdNbwdKW7NBh0tfabMHZng80Jc/jkSP28lQ== X-Received: by 2002:a05:620a:254e:b0:6b6:bc2:e083 with SMTP id s14-20020a05620a254e00b006b60bc2e083mr153879qko.317.1658254389799; Tue, 19 Jul 2022 11:13:09 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s5-20020a05620a0bc500b006b555509398sm15183389qki.136.2022.07.19.11.13.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2022 11:13:09 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id EF45D8006BB; Tue, 19 Jul 2022 13:13:07 -0500 (CDT) Date: Tue, 19 Jul 2022 13:13:07 -0500 From: Justin Pryzby To: Bruce Momjian Cc: pgsql-hackers@postgresql.org Subject: Re: First draft of the PG 15 release notes Message-ID: <20220719181307.GG12702@telsasoft.com> References: <20220719012322.GD12702@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jul 19, 2022 at 01:24:30PM -0400, Bruce Momjian wrote: > > > Remove pg_dump's --no-synchronized-snapshots option since all supported server versions support synchronized snapshots (Tom Lane) > > > > It'd be better to put that after the note about dropping support for upgrading > > clusters older than v9.2 in psql/pg_dump/pg_upgrade. > > Well, I put the --no-synchronized-snapshots item in incompatibilities > since it is a user-visible change that might require script adjustments. > However, I put the limit of pg_dump to 9.2 and greater into the pg_dump > section. Are you suggesting I move the--no-synchronized-snapshots item > down there? That doesn't match with the way I have listed other > incompatibilities so I am resistant to do that. I'd rather see the "limit support to v9.2" be moved or added to the "incompatibilities" section, maybe with "remove --no-synchronized-snapshots" as a secondary sentence. > > > 0. Add support for LZ4 and Zstandard compression of server-side base backups (Jeevan Ladhe, Robert Haas) > > > 1. Allow pg_basebackup to use LZ4 and Zstandard compression on server-side base backup files (Dipesh Pandit, Jeevan Ladhe) > > > 2. Allow pg_basebackup's --compress option to control the compression method and options (Michael Paquier, Robert Haas) > > > New options include server-gzip (gzip on the server), client-gzip (same as gzip). > > > 3. Allow pg_basebackup to compress on the server side and decompress on the client side before storage (Dipesh Pandit) > > > This is accomplished by specifying compression on the server side and plain output format. > > > > I still think these expose the incremental development rather than the > > user-facing change. > > > 1. It seems wrong to say "server-side" since client-side compression with > > LZ4/zstd is also supported. > > Agreed. I changed it to: > > Allow pg_basebackup to do LZ4 and Zstandard server-side compression > on base backup files (Dipesh Pandit, Jeevan Ladhe) This still misses the point that those compression algs are also supported on the client side, so it seems misleading to mention "server-side" support. > > > Allow custom scan provders to indicate if they support projections (Sven Klemm) > > > The default is now that custom scan providers can't support projections, so they need to be updated for this release. > > > > Per the commit message, they don't "need" to be updated. > > I think this should say "The default now assumes that a custom scan provider > > does not support projections; to retain optimal performance, they should be > > updated to indicate whether that's supported. > > Okay, I went with this text: > > The default is now that custom scan providers are assumed to not > support projections; those that do need to be updated for this > release. I'd say "those that do *will need to be updated" otherwise the sentence can sound like it means "those that need to be updated [will] ..." Thanks, -- Justin