Date: Mon, 14 Jan 2019 18:58:23 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
	Michael Paquier <michael.paquier@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Christoph Berg <myon@debian.org>,
	Thomas Munro <thomas.munro@enterprisedb.com>,
	Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Surjective functional indexes
Message-ID: <20190114235823.GY2528@tamriel.snowman.net>
References: <20180511143737.rvogcsxdksrhyyj5@alap3.anarazel.de>
 <CANP8+jLgdS-_ka5bhyG_=f5wGYVY-bQy3YD7rJY=TDnpA1snmg@mail.gmail.com>
 <CA+Tgmob_qk-w38Mbp5wCCGH9G8AFpmB0K0aTLujJqHNbBpBNUA@mail.gmail.com>
 <25975.1541618754@sss.pgh.pa.us>
 <20190114223409.3tcvejfhlvbucrv5@alap3.anarazel.de>
 <28044.1547507004@sss.pgh.pa.us>
 <20190114230918.fhp6wktbhg6pjnyw@alap3.anarazel.de>
 <28651.1547507948@sss.pgh.pa.us>
 <20190114234617.GW2528@tamriel.snowman.net>
 <30007.1547509982@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="kooh6sM6LkEI3mT2"
Content-Disposition: inline
In-Reply-To: <30007.1547509982@sss.pgh.pa.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> After a few minutes' more thought, I think that the most attractive
> >> option is to leave v11 alone and do a full revert in HEAD.  In this
> >> way, if anyone's attached "recheck_on_update" options to their indexes,
> >> it'll continue to work^H^H^H^Hdo nothing in v11, though they won't be
> >> able to migrate to v12 till they remove the options.  That way we
> >> aren't bound to the questionable design and naming of that storage
> >> option if/when we try this again.
>=20
> > So the plan is to add a check into pg_upgrade to complain if it comes
> > across any cases where recheck_on_update is set during its pre-flight
> > checks..?
>=20
> It wasn't my plan particularly.  I think the number of databases with
> that option set is probably negligible, not least because it was
> on-by-default during its short lifespan.  So there really has never been
> a point where someone would have had a reason to turn it on explicitly.
>=20
> Now if somebody else is excited enough to add such logic to pg_upgrade,
> I wouldn't stand in their way.  But I suspect just doing the revert is
> already going to be painful enough :-(

It seems like the thing to do would be to just ignore the option in v12+
pg_dump then, meaning that pg_dump wouldn't output it and
pg_restore/v12+ wouldn't ever see it, and therefore users wouldn't get
an error even if that option was used when they upgrade.

I could live with that, but you seemed to be suggesting that something
else would happen earlier.

> > What if v12 sees "recheck_on_update=3D'false'", as a v11
> > pg_dump might output today?
>=20
> It'll complain that that's an unknown option.

Right, that's kinda what I figured.  I'm not thrilled with that either,
but hopefully it won't be too big a deal for users.

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJcPSIfAAoJEO1sijiDR2RVSzMP/2lkGmZeW0yrXWeimHku6jbi
sRKa6be7rCr+Hr1GI2x7x3dvjXJG7+RqbnAJqB7T6OWqQqTYcP0t3IqpDce9QEMO
kXw38YiSLne2Lnb928qFKfLiubTxHvJsgTfo1MR73KVF4twAbiGSObX4jFxYWAqU
RssdOTNb18icZhK+wmxokIghJMTPlT4jc49pT8akkOiv4zDQXGm33Gq1gddENOVp
Xu9wPxPFnu/XU4aofCmYZyUVtw9nkBhHRhLDX11MruHqN9i2Qg0I/jgv97gUn8f7
7lsuSBIGSCWUSgVLs8y56jLFtiIXgN6HQM+WvkY1XSFfjQf2hr1oZeMnWP9EHQii
UAgLWqH15s0k60cTuPrHtE0mS7c2CDC8dikQG3faW5P4xESFEmyMs5yqcLAzkqQc
5cVcvSM4hapP9fdFF+fuveWu5upRRKisjUhBofgm/NPRjpFih8ayK5yJOhXflvOE
Gm4FyEQaXBovNwonkjPzY7DeSB9NmH8IefKDB01MGW7jIUl9vauENxsy1IJpGsMe
pids84YWHbb8PCzMHxNyW6rsneee8Z39oT/HPUL+9EStYmQ29hdM8jq1zPbSYQi6
AgZ8vYvY5kSVRo/Lv2GQjrspawxyzpGMy2bcXESzUOVViQV1MqjpiH00zXUyLBG2
KWz+2MkWWQlFOFcXILxp
=RAhx
-----END PGP SIGNATURE-----

--kooh6sM6LkEI3mT2--