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

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 :)

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.

> > 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...

> > 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

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.

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.

Justin