Re: Hard limit on WAL space used (because PANIC sucks)

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Hard limit on WAL space used (because PANIC sucks)
Дата
Msg-id 51B8E223.8040705@commandprompt.com
обсуждение исходный текст
Ответ на Re: Hard limit on WAL space used (because PANIC sucks)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Hard limit on WAL space used (because PANIC sucks)  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On 06/12/2013 08:49 AM, Robert Haas wrote:

> Sure, remote archiving is great, and I'm glad you've been working on
> it.  In general, I think that's a cleaner approach, but there are
> still enough people using archive_command that we can't throw them
> under the bus.

Correct.

>
>> I guess archiving to a nfs mount or so isn't too bad, but archiving and
>> using a cronjob to get the files off is typically a great way to loose data,
>> and we really shouldn't encourage that by default, Imo.
>

We certainly not by default but it is also something that can be easy to 
set up reliably if you know what you are doing.


> Well, I think what we're encouraging right now is for people to do it
> wrong.  The proliferation of complex tools to manage this process
> suggests that it is not easy to manage without a complex tool.

No. It suggests that people have more than one requirement that the 
project WILL NEVER be able to solve.

Granted we have solved some of them, for example pg_basebackup. However, 
pg_basebackup isn't really useful for a large database. Multithreaded 
rsync is much more efficient.


>  That's
> a problem.  And we regularly have users who discover, under a variety
> of circumstances, that they've been doing it wrong.  If there's a
> better solution than hard-wiring some smarts about local directories,
> I'm all ears - but making the simple case just work would still be
> better than doing nothing.

Agreed.


>  Right now you have to be a rocket
> scientist no matter what configuration you're running.

This is quite a bit overblown. Assuming your needs are simple. Archiving 
is at it is now, a relatively simple process to set up, even without 
something like PITRTools.  Where we run into trouble is when they aren't 
and that is ok because we can't solve every problem. We can only provide 
tools for others to solve their particular issue.

What concerns me is we seem to be trying to make this "easy". It isn't 
supposed to be easy. This is hard stuff. Smart people built it and it 
takes a smart person to run it. When did it become a bad thing to be 
something that smart people need to run?

Yes, we need to make it reliable. We don't need to be the Nanny database.

JD

-- 
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms   a rose in the deeps of my heart. - W.B. Yeats



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

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: Hard limit on WAL space used (because PANIC sucks)