Date: Wed, 16 Oct 2019 17:44:24 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: "imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>,
	Euler Taveira <euler@timbira.com.br>, Tom Lane <tgl@sss.pgh.pa.us>,
	Andrew Gierth <andrew@tao11.riddles.org.uk>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: v12 and pg_restore -f-
Message-ID: <20191016214424.GK6962@tamriel.snowman.net>
References: <875zl11tla.fsf@news-spur.riddles.org.uk>
 <30069.1570396524@sss.pgh.pa.us>
 <20191008180840.GQ6962@tamriel.snowman.net>
 <CAHE3wgi=VU0G9=S60=gQH+yyk8-Ke99dkt8Dp4OpZXkSu=67fQ@mail.gmail.com>
 <20191009124505.GT6962@tamriel.snowman.net>
 <OSBPR01MB4616298336E32F8EAEDA0FF394920@OSBPR01MB4616.jpnprd01.prod.outlook.com>
 <20191016172148.GH6962@tamriel.snowman.net>
 <20191016175838.GL3599@telsasoft.com>
 <20191016190452.GJ6962@tamriel.snowman.net>
 <20191016192840.GO3599@telsasoft.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Jf0PKkSyCPGBCVtN"
Content-Disposition: inline
In-Reply-To: <20191016192840.GO3599@telsasoft.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Justin Pryzby (pryzby@telsasoft.com) wrote:
> On Wed, Oct 16, 2019 at 03:04:52PM -0400, Stephen Frost wrote:
>=20
> > > On Wed, Oct 16, 2019 at 01:21:48PM -0400, Stephen Frost wrote:
> > > > [...] if they actually need to work with both concurrently (which s=
trikes me
> > > > as already at least relatively uncommon...).
> > >=20
> > > I doubt it's uncommon.  In our case, we have customers running centos=
6 and 7.
> > > There's no postgis RPMs provided for centos6 which allow an upgrade p=
ath to
> > > v12, so we'll end up supporting at least (centos6, pg11) and (centos7=
,pg12) for
> > > months, at least.
> >=20
> > I suppose the issue here is that you don't want to have different
> > versions of some scripts for centos6/pg11 vs. centos7/pg12?  I'm a bit
> > surprised that you don't have to for reasons unrelated to pg_restore.
>=20
> Right, I don't want to "have to" do anything :)

Sure, fair enough.

> If we really need a separate script, or conditional, then we'll do, but i=
t's
> nicer to be ABLE write something (like this sanity check) in one line and=
 not
> NEED TO write it in six.  So far these maint scripts have significant a b=
it
> telsasoft-specific logic, but very little specific to postgres versions. =
 I
> recall the schema-qualification stuff caused some churn, but it was in a =
minor
> release, so everyone was upgraded within 30-40 days, and if they weren't,=
 I
> probably knew not to deploy updated scripts, either.

Hmm, that's interesting as a data point, at least.

> > > I'd *like* to be able to deploy our most recent maint scripts during =
the
> > > interval of time our customers are running different major versions. =
 The
> > > alternative being to try to remember to avoid deploying updated v12 s=
cripts at
> > > customers still running v11.  I went to the effort to make our vacuum=
/analyze
> > > script support both versions following the OID change.
> >=20
> > And I suppose you don't want to install v12 client tools for the v11
> > systems..?  I get that there's an argument for that, but it does also
> > seem like it'd be an alternative solution.
>=20
> Hm, I'd be opened to it, except that when I tries this during beta, the P=
GDG
> RPMs are compiled with GSSAPI, which creates lots of warnings...but maybe
> that's just in nagios...

Warnings in the server log because they attempt to start a GSSAPI
encrypted session first, if you are authenticating with GSSAPI?  If so
then I'm sympathetic, but at least you could address that by setting
PGGSSENCMODE to disable, and that'd work for pre-v12 and v12+.

> > > Tom's proposed in February to backpatch the -f- behavior, so ISTM tha=
t we're
> > > right now exactly where we (or at least he) planned to be, except tha=
t the
> > > backpatch ideally should've been included in the minor releases in Au=
gust,
> > > before v12 was released.
> > >=20
> > > https://www.postgresql.org/message-id/24868.1550106683%40sss.pgh.pa.us
> >=20
> > That continues to strike me as a good way forward, and I'm guessing you
> > agree on that?  If so, sorry for not including you in my earlier email.
>=20
> I believe you did include me (?) - I started the thread (on -general).
> https://www.postgresql.org/message-id/20191016172148.GH6962%40tamriel.sno=
wman.net

Ah, no, I mean in the list of who was taking what position- I only named
Yoshikazu Imai, Andrew, Eurler, Tom and myself.

> I think it's a good idea to do some combination of backpatching -f-, and =
maybe
> document behavior of pre-12 pg_restore in v12 release notes, and suggest
> /dev/stdout as a likely workaround.  Of course, if backpatched, the behav=
ior of
> pre-12 will vary, and should be documented as such, which is a kind of al=
ot,
> but well.
>=20
> |In pg_restore, require specification of -f - to send the dump contents t=
o standard output (Euler Taveira)
> |Previously, this happened by default if no destination was specified, bu=
t that was deemed to be unfriendly.
> |In the latest minor releases of versions v11 and earlier, pg_restore -f =
- is updated for
> |consistency with the new behavior of v12, to allow scripts to be written=
 which
> |work on both.  But note that earlier releases of v9.3 to v11 don't speci=
ally
> |handle "-f -", which will cause them to write to a file called "-" and n=
ot
> |stdout.  If called under most unix shells, -f /dev/stdout will write to =
stdout on all versions of pg_restore.

We'd probably have to list the specific minor versions instead of just
saying "latest" and if we're suggesting an alternative course of action
then we might want to actually include that in the documentation
somewhere..  I'm not really sure that we want to get into such
platform-specific recommendations though.

> It's not perfect - someone who wants portable behavior has to apply Novem=
ber's
> minor upgrade before installing any v12 server.  And vendors (something l=
ike
> pgadmin) will end up "having to" write to a file to be portable, or else =
check
> the full version, not just the major version.

See- folks like pgadmin I would expect to have to routinely write custom
code for each version since the goal there is to support all of the
options available from the utility, so I'm not really sure that this
would actually be much of a hardship for them.  Of course, I don't
really hack on pgAdmin, so I might be wrong there.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJdp483AAoJEO1sijiDR2RVTq0QAKR4hMTJATSo9MmfEc0eJ1SV
IdVLXll+iYbdPDXmrZdNJXktoobVs6cx1sX7QaFPV/wiIElyoY45xJLOKK3Ue+zm
XewTuDZpvBs/Fb0F1apmlCKMemGdKNAp/X3dZCWA3ZvZRj9IyYQtVwBFyp7Z0Ija
u/SFsoIUC8XSjaZSfu0Q1vQGzH/CJ/HYbFdaytyspGufWgL7YZXZRzOcJP75KQ7H
R4YPQHU8DvD+D7oW1wP/bTUsa9jUpYyCOxRJs4aIp8p1lHXFIrb7gft3jsEN8/gG
GUcipZclMfOHP09I6iyRQnmZNXJ64+yetDOfzP0v+/wEEXsi+AqmUEStqP5OTW4I
5Diu0i9smmN4pXnuC0TM8QIeqs3pGpAoXJ+Rm/rS3mgXnVtQYlivHKQnXScJLCmm
IML+RJLLS/M+RNvEHHtNKv8v8DX5jNfRN8LKEG+uK9/o2o+y/BdvI5eYXCPx8lKP
zOwvxh/MVkla3Zo74rB0/1iIZk0zd6UqInXPx22P0cCGp6uAK6DaxfWmDBSb9Y0w
565tAsytJunfUEwfasz3tZ65AWzRmHT/HEx4VNHp72uLFOlTrs275Xu2P7HnqSi/
VQrkQpVG2q/5SYCJdj+10porHKj6thRMfmqa338VuOroCHxC/9LO/j4rO77ME9au
IwZrUhcQbDm0KyAHCwWE
=J3XR
-----END PGP SIGNATURE-----

--Jf0PKkSyCPGBCVtN--