Re: v12 and pg_restore -f- - Mailing list pgsql-hackers

Greetings,

* Justin Pryzby (pryzby@telsasoft.com) wrote:
> On Wed, Oct 16, 2019 at 03:04:52PM -0400, Stephen Frost wrote:
>
> > > On Wed, Oct 16, 2019 at 01:21:48PM -0400, Stephen Frost wrote:
> > > > [...] if they actually need to work with both concurrently (which strikes me
> > > > as already at least relatively uncommon...).
> > >
> > > I doubt it's uncommon.  In our case, we have customers running centos6 and 7.
> > > There's no postgis RPMs provided for centos6 which allow an upgrade path to
> > > v12, so we'll end up supporting at least (centos6, pg11) and (centos7,pg12) for
> > > months, at least.
> >
> > 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.
>
> 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 it'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 bit
> 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 scripts at
> > > customers still running v11.  I went to the effort to make our vacuum/analyze
> > > script support both versions following the OID change.
> >
> > 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.
>
> Hm, I'd be opened to it, except that when I tries this during beta, the PGDG
> 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 that we're
> > > right now exactly where we (or at least he) planned to be, except that the
> > > backpatch ideally should've been included in the minor releases in August,
> > > before v12 was released.
> > >
> > > https://www.postgresql.org/message-id/24868.1550106683%40sss.pgh.pa.us
> >
> > 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.
>
> I believe you did include me (?) - I started the thread (on -general).
> https://www.postgresql.org/message-id/20191016172148.GH6962%40tamriel.snowman.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 behavior of
> pre-12 will vary, and should be documented as such, which is a kind of alot,
> but well.
>
> |In pg_restore, require specification of -f - to send the dump contents to standard output (Euler Taveira)
> |Previously, this happened by default if no destination was specified, but 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 specially
> |handle "-f -", which will cause them to write to a file called "-" and not
> |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 November's
> minor upgrade before installing any v12 server.  And vendors (something like
> 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