Re: Sync Rep: First Thoughts on Code - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Sync Rep: First Thoughts on Code
Date
Msg-id 1229111768.12977.41.camel@dell.linuxdev.us.dell.com
Whole thread Raw
In response to Re: Sync Rep: First Thoughts on Code  (Aidan Van Dyk <aidan@highrise.ca>)
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: benchmarking the query planner
Next
From: Tom Lane
Date:
Subject: Re: benchmarking the query planner