pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Tue, 14 Dec 2021 17:18:44 -0500
Message-ID: <556122.1639520324@sss.pgh.pa.us> (raw)
In-Reply-To: <70194.1639290264@sss.pgh.pa.us>
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
	<202110222351.3f42l5fgo3lw@alvherre.pgsql>
	<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
	<3783090.1635111977@sss.pgh.pa.us>
	<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
	<3883429.1635171820@sss.pgh.pa.us>
	<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
	<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
	<22018.1635202338@sss.pgh.pa.us>
	<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
	<20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
	<196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
	<2316211.1638556231@sss.pgh.pa.us>
	<CA+Tgmob0V3dJ57vKL1iouk1oLMFn-60eAUQ+ab6=1BDG7ZC8iw@mail.gmail.com>
	<2978297.1638751274@sss.pgh.pa.us>
	<3794414.1639072240@sss.pgh.pa.us>
	<6f92dea3-9619-be68-239f-8990a832b453@dunslane.net>
	<70194.1639290264@sss.pgh.pa.us>

I wrote:
> Anyway, it seems like there's some consensus that 9.2 is a good
> stopping place for today.  I'll push forward with
> (1) back-patching as necessary to make 9.2 and up build cleanly
> on the platforms I have handy;
> (2) ripping out pg_dump's support for pre-9.2 servers;
> (3) ripping out psql's support for pre-9.2 servers.

I've completed the pg_dump/pg_dumpall part of that, but while
updating the docs I started to wonder whether we shouldn't nuke
pg_dump's --no-synchronized-snapshots option.  As far as I can
make out, the remaining use case for that is to let you perform an
unsafe parallel dump from a standby server of an out-of-support
major version.  I'm not very clear why we allowed that at all,
ever, rather than saying you can't parallelize in such cases.
But for sure that remaining use case is paper thin, and leaving
the option available seems way more likely to let people shoot
themselves in the foot than to let them do anything helpful.

Barring objections, I'll remove that option in a day or two.

			regards, tom lane





view thread (70+ messages)  latest in thread

Message-ID: <556122.1639520324@sss.pgh.pa.us>
Permalink:  ../556122.1639520324@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/556122.1639520324@sss.pgh.pa.us

 · 

reply
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: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, andrew@dunslane.net, andres@anarazel.de, robertmhaas@gmail.com, bruce@momjian.us, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
  Subject: Re: pg_dump versus ancient server versions
  In-Reply-To: <556122.1639520324@sss.pgh.pa.us>

* 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