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

Greetings,

* Justin Pryzby (pryzby@telsasoft.com) wrote:
> On Sun, Oct 06, 2019 at 04:43:13PM -0400, Tom Lane wrote:
> > Nobody is going to wish that to mean "write to a file named '-'", so
>
> Probably right, but it occurs to me that someone could make a named pipe called
> that, possibly to make "dump to stdout" work with scripts that don't support
> dumping to stdout, but with what's arguably a self-documenting syntax.

I'm not super keen to stress a great deal over "someone could" cases.
Yes, we can come up with lots of "what ifs" here to justify why someone
might think to do this but it still seems extremely rare to me.  It'd be
nice to get some actual numbers somehow but I haven't got any great
ideas about how to do that.  Actual research into this would probably be
to go digging through source code that's available to try and figure out
if such a case exists anywhere public.

> On Wed, Oct 09, 2019 at 09:07:40AM -0300, Euler Taveira wrote:
> > > Maintenance scripts break across major versions.
> ...
> > Yeah, if you check pg_restore version, you could use new syntax for
> > 12+. We break scripts every release (mainly with catalog changes) and
> > I don't know why this change is different than the other ones. The
> > pg_restore changes is more user-friendly and less error-prone.
>
> The issue isn't that scripts broke, but that after I fixed scripts to work with
> v12, it's impossible (within pg_restore and without relying on shell or linux
> conventions) to write something that works on both v11 and v12, without
> conditionalizing on pg_restore --version.

Right- you were happy (more-or-less) to update the scripts to deal with
the v12 changes, but didn't like that those changes then broke when run
against v11, something that would be fixed by correcting those earlier
versions.

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

> I have a half dozen maintenance scripts to do things like reindex, vacuum,
> cluster, alter tblspace.  In the immediate case, our backup script runs
> pg_restore to check if an existing pg_dump backup of an old table is empty when
> the table is not itself empty - which has happened before due to logic errors
> and mishandled DST...  (We're taking advantage of timeseries partitioning so
> daily backups exclude tables older than a certain thershold, which are assumed
> to be unchanged, or at least not have data updated).
>
> 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.

> I worked around the pg_restore change using /dev/stdout ; possibly the
> documentation should mention that workaround for portability to earlier
> versions: that would work for maybe 85% of cases.  If need be, one could check
> pg_restore --version.  But it's nicer not to need to.
>
> 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.

Thanks,

Stephen