Thread: pgsql: Remove pg_dump's --no-synchronized-snapshots switch.

Remove pg_dump's --no-synchronized-snapshots switch.

Server versions for which there was a plausible reason to
use this switch are all out of support now.  Leaving it
around would accomplish little except to let careless DBAs
shoot themselves in the foot.

Discussion: https://postgr.es/m/556122.1639520324@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/2a712066d0587f65fcecd44e884dc6a09958dbdd

Modified Files
--------------
doc/src/sgml/ref/pg_dump.sgml | 14 +-------------
src/bin/pg_dump/pg_backup.h   |  1 -
src/bin/pg_dump/pg_dump.c     | 11 ++---------
3 files changed, 3 insertions(+), 23 deletions(-)

On 12/16/21 00:45, Tom Lane wrote:
> Remove pg_dump's --no-synchronized-snapshots switch.
> 
> Server versions for which there was a plausible reason to
> use this switch are all out of support now.  Leaving it
> around would accomplish little except to let careless DBAs
> shoot themselves in the foot.
> 
> Discussion: https://postgr.es/m/556122.1639520324@sss.pgh.pa.us
> 

Hello,

I have seen one situation where this option could have been useful even on 
recent Postgres version:

Few years ago, I have seen an instance hit wraparound (1 million transactions 
left) due to a bug (vacuum didn't freeze some blocks, bug has been fixed since).

I had to perform a dump/restore, but can't use parallel dump as Postgres refused 
to export transaction snapshot. So the dump was ... long.

Late in the night, I didn't notice I could have used --no-synchronized-snapshots 
to perform parallel dump. As Postgres didn't accept new transaction, there was 
no risk of incoherent dump.

I don't know if we should keep this option. I just want to share a case where 
this option could have been useful.


Regards,

-- 
Adrien