From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Christoph Berg <myon@debian.org>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Surjective functional indexes
Date: Mon, 14 Jan 2019 18:58:23 -0500
Message-ID: <20190114235823.GY2528@tamriel.snowman.net> (raw)
In-Reply-To: <30007.1547509982@sss.pgh.pa.us>
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>
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.
>
> > 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..?
>
> 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.
>
> 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='false'", as a v11
> > pg_dump might output today?
>
> 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
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, tgl@sss.pgh.pa.us, andres@anarazel.de, simon@2ndquadrant.com, robertmhaas@gmail.com, k.knizhnik@postgrespro.ru, michael.paquier@gmail.com, alvherre@alvh.no-ip.org, myon@debian.org, thomas.munro@enterprisedb.com, peter.eisentraut@2ndquadrant.com
Subject: Re: [HACKERS] Surjective functional indexes
In-Reply-To: <20190114235823.GY2528@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox