Date: Thu, 7 Apr 2022 16:09:56 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Preventing indirection for IndexPageGetOpaque for known-size
 page special areas
Message-ID: <20220407200955.GA10577@tamriel.snowman.net>
References: <YkaP64JvZTMgcHtq@paquier.xyz>
 <CAEze2WiE=5bHDSSKX9RCZKqGLqz4F5OX5pQmUn5CpU88j470zg@mail.gmail.com>
 <CAEze2Wj9c0abW2aRbC8JzOuUdGurO5av6SJ2H83du6tM+Q1rHQ@mail.gmail.com>
 <CA+TgmoZGjCLvDxATQOgthcnYXjRQ-E_hE+QdHoisZCfVhg1VvA@mail.gmail.com>
 <CAEze2Wg0OxFFA96kf0PHNL9mbjYUBwnxhxFrOn-GudNiKq0aLA@mail.gmail.com>
 <CA+TgmoZf6GL4e=b5XKbNHQjXT4M0ewjBC91ZOrxLnhogY9Ha9w@mail.gmail.com>
 <CAH2-WzkqGMbc2bbm2zwoSpy2RpH0KSvhMcyD6qWewPUbBy8gdg@mail.gmail.com>
 <CA+TgmobQtf7hMNLtbPa9KUcsQ3oWquCL2OMzCcKPymTw8i1odg@mail.gmail.com>
 <CAH2-WznLqEyST-zJ8jzzdjGQqq-Qf0YhthxWF=P495BsfF_3cg@mail.gmail.com>
 <CA+TgmoaCWKbT+y2N8KC8Xr9dKgRcLxyBcdRenHBgDAg3FOpK5A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="wgm2yIPwznlIwrCm"
Content-Disposition: inline
In-Reply-To: <CA+TgmoaCWKbT+y2N8KC8Xr9dKgRcLxyBcdRenHBgDAg3FOpK5A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://www.postgresql.org/message-id/20220407200955.GA10577%40tamriel.snowman.net>
Precedence: bulk


--wgm2yIPwznlIwrCm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Apr 7, 2022 at 3:27 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > I just meant that it wouldn't be reasonable to impose a fixed cost on
> > every user, even those not using the feature. Which you said yourself.
>=20
> Unfortunately, I think there's bound to be some cost. We can avoid
> using the space in the page for every user, but anything that makes
> the page layout variable is going to cost some number of CPU cycles
> someplace. We have to measure that overhead and see if it's small
> enough that we're OK with it.

Agreed that there may be some cost in CPU cycles for folks who don't
initialize the database with an option that needs this, but hopefully
that'll be quite small.

> > I got that much, of course. That will work, I suppose, but it'll be
> > the first and last time that anybody gets to do that (unless we accept
> > it being incompatible with encryption).
>=20
> Yeah.

I don't know that I agree with this being the 'first and last time'..?
If we have two options that could work together and each need some
amount of per-page space, such as a nonce or authentication tag, we'd
just need to be able to track which of those are enabled (eg: through
pg_control) and then know which gets what space.  I don't see why we
couldn't add something today and then add something else later on.  I do
think there'll likely be cases where we have two options that don't make
sense together and we wouldn't wish to allow that (such as page-level
strong checksums and authenticated encryption, as the latter provides
the former inherently) but there could certainly be things that do work
together too.

> > > If we *didn't* put the nonce at the end of the page, where else would
> > > we put it? It has to be at a fixed offset, because otherwise you can't
> > > find it without decrypting the page first, which would be circular.
> >
> > Immediately before the special area proper (say BTOpaque), which would
> > "logically come after" the special space under this scheme. You
> > wouldn't have a simple constant offset into the page, but you'd have
> > something not too far removed from such a constant. It could work as a
> > constant with minimal context (just the AM type). Just like with
> > Matthias' patch.
>=20
> I don't think this would work, because I don't think it would be
> practical to always know the AM type. Think about applying an XLOG_FPI
> record, for example.

I'm also doubtful about how well this would work, but the other question
is- what would be the advantage to doing it this way?  If we could have
it be run-time instead of initdb-time, that'd be great (imagine a
database that's encrypted while another isn't in the same cluster, or
even individual tables, which would all be very cool), but I don't think
this approach would make that possible..?

(sorry for only just seeing this thread getting traction, have been a
bit busy with other things ...)

Thanks,

Stephen

--wgm2yIPwznlIwrCm
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJiT0UTAAoJEO1sijiDR2RVzSUP/0L8tLhjKw9djsoJU+XrsNNn
C+BTCZij1xVuWhlIDl3bWD64jeMGKYT1HhGl0fXl/by2DPuq02XPPQ1DWEkSnPPk
BrudeHndqYVQW8w5ZWrGoglwpYtWG7whMATytQiufqIP0Fo8ZE1Ljo2V6cvky9m0
ExKg+of7iRX4zhWrWo+HkCBQpJvUvxNYAUKvZeMFc8kHU61VTceojCHfjdlBkWRN
8KGWk9xiZN60uh193712xr0OZICBK18jqssRfDiQq4QKZRhANe/SnlbCKKg/yB3k
56QHRKMs25UyQU8S+JFZ/htvnFnGjczp58qE8olR6E58pRNulIvB5sDprgA35a16
REMWZtb1DrsvtK92CHY+FgIhBEaVliVUarzeHxTr3CB5GNdNNQ/CWQt3dHMnJ7XE
3lboFVN8png4vF2+7bv7CbMFCc3lg28Q7HqFNcwX02FVc4JkQlUj2r/zEEViWksH
GQMcTobLvqbUiqq0XN/2TYqhPstLTLklDflDqtyKoimssEQjCDHPxpnSdC2c7WsC
eQ/NVQYXyUcXTsj4DZd6LedFExaJyakVF9132VDZfoe/XE8l0EJpkVM6HTjxbD0m
HUWPkxyWnUADPCezEiRLdHV5XAh59D32KU97YvUpdKk2gLc5QmzdCzHCsZsIpFta
6S3iZLtkGjXisOLRLuZB
=xmJj
-----END PGP SIGNATURE-----

--wgm2yIPwznlIwrCm--