Re: Remove Deprecated Exclusive Backup Mode
От | Stephen Frost |
---|---|
Тема | Re: Remove Deprecated Exclusive Backup Mode |
Дата | |
Msg-id | 20190222231812.GD6197@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Remove Deprecated Exclusive Backup Mode (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Remove Deprecated Exclusive Backup Mode
(Christophe Pettus <xof@thebuild.com>)
Re: Remove Deprecated Exclusive Backup Mode (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > 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. Yes, they are- but I'd argue that's specifically because the old/deprecated/broken API makes it *look* safe, even though it isn't. Getting a solid and resiliant backup to work from a shell script is, imv anyway (though I might have a bit of experience, having tried numerous times myself and then realizing that it just isn't practical...), a downright fool's errand. Perhaps there's some way we can fix that so that people can write a lazy rsync-based backup script and use it, but I don't see anyone seriously working on that and I don't think that's because they just really like to make things difficult for people but rather because it really is *hard* to do, if not downright impossible. What we need is a backup tool included in core that users feel comfortable using instead of trying to write their own. I don't think they write their own because it's somehow better than the existing tools or because they really think it's a good idea- it's just what looks like the "thing to do" based on our documentation and the API we provide today. Sure, pg_basebackup is good for smaller environments and I always encourage people to use it when they want something that's in core that is safe to use and that does things correctly, but it's got some pretty serious limitations due to using the replication protocol. Thanks! Stephen
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Andres FreundДата:
Сообщение: Re: Refactoring the checkpointer's fsync request queue