Re: Remove Deprecated Exclusive Backup Mode

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Remove Deprecated Exclusive Backup Mode
Дата
Msg-id CA+TgmoZ+7WcLc0UyriSht0TExmBVj_tFFEm4w223U2qXr2YJ4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove Deprecated Exclusive Backup Mode  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Remove Deprecated Exclusive Backup Mode  (Stephen Frost <sfrost@snowman.net>)
Re: Remove Deprecated Exclusive Backup Mode  (Adrien NAYRAT <adrien.nayrat@anayrat.info>)
Список pgsql-hackers
On Fri, Feb 22, 2019 at 12:35 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> -1 for the removal. I think that there are still many users of an exclusive
> backup API, and it's not so easy to migrate their backup scripts so that
> only non-exclusive one is used because of the reason I wrote in another thread.
> https://postgr.es/m/CAHGQGwHUkEbkVexVfWNLjmq2rzOS_SHYMiECt+KBn-cBPq5Arg@mail.gmail.com

Yeah, those are interesting points.  Unfortunately, I think something
as simple as your proposed...

psql -c "SELECT pg_start_backup()"
rsync, cp, tar, storage backup, or something
psql -c "SELECT pg_stop_backup()"

...doesn't have much chance of being correct.  If you aren't checking
whether pg_start_backup() throws an error, for example, you have got a
very failure-prone set-up.  That being said, it's possible to fix that
problem using some shell logic, whereas the problem of keeping a
connection open for the duration of the backup from the shell is much
harder.  I recently ran across a case where someone attempted it but
did not get the logic entirely right, with rather painful
consequences.

Now you might say that people should not write their own tools and
just use professionally produced ones.  But I don't really agree with
that, and whatever we think people SHOULD do, there are in fact a lot
of people using their own tools.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Autovaccuum vs temp tables crash
Следующее
От: Corey Huinker
Дата:
Сообщение: Re: some ri_triggers.c cleanup