Date: Mon, 14 Jan 2019 18:55:18 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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: <20190114235518.GX2528@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>
 <20190114235115.lpapnfcezuoyizo2@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="FBSnKVgIBiLykaLX"
Content-Disposition: inline
In-Reply-To: <20190114235115.lpapnfcezuoyizo2@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2019-01-14 18:46:18 -0500, Stephen Frost wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > Andres Freund <andres@anarazel.de> writes:
> > > > On 2019-01-14 18:03:24 -0500, Tom Lane wrote:
> > > >> Do we want to revert entirely, or leave the "recheck_on_update" op=
tion
> > > >> present but nonfunctional?
> > >=20
> > > > I think it depends a bit on whether we want to revert in master or
> > > > master and 11. If only master, I don't see much point in leaving the
> > > > option around. If both, I think we should (need to?) leave it aroun=
d in
> > > > 11 only.
> > >=20
> > > 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 indexe=
s,
> > > 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
> I don't think so.

I could possibly see us just ignoring the option in pg_dump, but that
goes against what Tom was suggesting, since users wouldn't see an error
if we don't dump the option out..

> > Or are you suggesting that pg_dump in v12+ would throw errors if it
> > finds that set?  Or that we'll dump it, but fail to allow it into a
> > v12+ database?  What if v12 sees "recheck_on_update=3D'false'", as a v11
> > pg_dump might output today?
>=20
> It'll just error out on restore (including the internal one by
> pg_upgrade). I don't see much point in doing more, this isn't a widely
> used option by any stretch.

This.. doesn't actually make sense.  The pg_upgrade will use v12+
pg_dump.  You're saying that the v12+ pg_dump will dump out the option,
but then the restore will fail to understand it?

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJcPSFmAAoJEO1sijiDR2RVpZ8P/2NahsRsN9m8b0zXbl3PZUc+
8HaSlZ9RQRIHK9Hw5bNufxpjHXOqxoArTJv1bl2pmEqBaORZhfOx0g9VmkAg05DA
e+9GVUGQw+7w8ypLuc7XbMgQVQ9xPoxRQ3kf1pLD2xkz/o9It4j7S/o0ZcgdvjhH
1JBtJsskDFq8qnfJfYkgFDCOI8UH+iULaKF5uPzF22zAzNQ2KIYYPDAwi2TNV4y0
GDi/O7ScZL+pvdh/n/H3mKQWOIQfgRcqMuHRd0pOf5nzlxCtnpeNkY0n9z128XDY
zAzNdfFSFNd8PcBd4P/KFG9ajb8Dijoz10NtKKhfMrP2wIr4TR5OnYegcx+X+CO5
R8N5QXE9ZgsafwRBKh1ahd7nLQNo1y9kILVpBpjmE8k3mrkyOm2TYrfz9On5CPy2
Le5xfFdcfrTdy5Cd6Ztovlm7kMeJAuluOqKpo0dZipUU+0IdfBtc2IRAIwLyrzxq
sZvpduWGnYpkaVLWqbuo0ma9N4BLuTLqYPA2Cl/6fwCHjhp1X7yHxwZ9dk84br1c
f/U7dYbpTSK7rb++xat4yeRltDAy+K+47AURtMMIIGzwhbhoniW2t6bxTVsMbqgC
1RyEMxk41T9fcBvLa5J+3Ru28NOdpVy2tjeChVvUZkkGZa+htK+303UoDwinvZkX
9rvMIs8b5yKbywnk0T08
=7M6h
-----END PGP SIGNATURE-----

--FBSnKVgIBiLykaLX--