Re: Better handling of archive_command problems
От | Robert Haas |
---|---|
Тема | Re: Better handling of archive_command problems |
Дата | |
Msg-id | CA+TgmoZcO9b0poY6NQrb9RR7_mindAoHp2XxidQK3XD-3fvVrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Better handling of archive_command problems (Daniel Farina <daniel@heroku.com>) |
Ответы |
Re: Better handling of archive_command problems
|
Список | pgsql-hackers |
On Thu, May 16, 2013 at 10:06 PM, Daniel Farina <daniel@heroku.com> wrote: > Do you have a sketch about mechanism to not encounter that problem? I didn't until just now, but see my email to Peter. That idea might be all wet, but off-hand it seems like it might work... > However little it may matter, I would like to disagree with your > opinion on this one: the current situation as I imagine encountered by > *all* users of archiving is really unpleasant, 'my' shop or no. It > would probably not be inaccurate to say that 99.9999% of archiving > users have to live with a hazy control over the amount of data loss, > only bounded by how long it takes for the system to full up the WAL > file system and then for PostgreSQL to PANIC and crash (hence, no more > writes are processed, and no more data can be lost). I'm really not trying to pick a fight here. What I am saying is that it is the problem is not so bad that we should accept the first design proposed, despite the obvious problems with it, without trying to find a better one. The first post to -hackers on this was 4 days ago. Feature freeze for the first release that could conceivably contain this feature will most likely occur about 8 months from now. We can take a few more days or weeks to explore alternatives, and I believe it will be possible to find good ones. If I were trying to kill this proposal, I could find better ways to do it than clearly articulating my concerns at the outset. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: