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: /messages/by-id/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: /messages/by-id/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