| From: | Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Remove pg_dump's --no-synchronized-snapshots switch. |
| Date: | 2021-12-17 15:40:33 |
| Message-ID: | 119eacbf-2f89-7f26-a0f3-71adff4ccbcc@anayrat.info |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-12-17 17:52:39 | Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas |
| Previous Message | Peter Eisentraut | 2021-12-17 05:44:59 | pgsql: Simplify the general-purpose 64-bit integer parsing APIs |