Re: Sync Rep: First Thoughts on Code

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Sync Rep: First Thoughts on Code
Дата
Msg-id 1229111768.12977.41.camel@dell.linuxdev.us.dell.com
обсуждение исходный текст
Ответ на Re: Sync Rep: First Thoughts on Code  (Aidan Van Dyk <aidan@highrise.ca>)
Список pgsql-hackers
On Fri, 2008-12-12 at 14:23 -0500, Aidan Van Dyk wrote:
> So when would I have to call that function? Before begin, after begin,
> before commit, or all, to guarentee that know that my application is
> suppose to "delay" calling commit until when sync-mode is actualyl
> synchronous? And then afterwards, I have to call it again t omake sure
> it didn't fall "out of" mode between my previous call and the commit
> actually working?

I'm not suggesting that applications call the function. It's a way for a
monitoring system to know that you're in a degraded state and notify
you.

I'm not sure I entirely understand the use case you're advocating:

Let's say the standby has a major failure. Now you have a single point
of failure (the primary), so _all_ of your transactions are in jeopardy
anyway -- at least until you get back into sync rep. Rejecting new
transactions won't save your old ones.

The only time it helps is when the failure is temporary, i.e. you didn't
really lose the storage on the standby. But you would need to rely on
some guarantee that the storage is still intact on the standby system
even though the standby is unresponsive.

Is that the use case?

Regards,Jeff Davis






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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: benchmarking the query planner
Следующее
От: Tom Lane
Дата:
Сообщение: Re: benchmarking the query planner