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

Поиск
Список
Период
Сортировка
От Adrien Nayrat
Тема Re: pgsql: Remove pg_dump's --no-synchronized-snapshots switch.
Дата
Msg-id 119eacbf-2f89-7f26-a0f3-71adff4ccbcc@anayrat.info
обсуждение исходный текст
Ответ на pgsql: Remove pg_dump's --no-synchronized-snapshots switch.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-committers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: Simplify the general-purpose 64-bit integer parsing APIs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Revoke PUBLIC CREATE from public schema, now owned by pg_databas