On Mon, Nov 5, 2012 at 1:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Well, feel free to make a suggestion. We could have a mode where a
> commit, once initiated, is not user-cancellable, but that doesn't seem
> like a usability improvement to me. That just forces somebody to
> bounce the server in a situation where it isn't necessary. The
> warning is not unclear about what has happened.
Yeah, I'm not quite so far as thinking about the best way (much less
any way) of solving the problem, only so far as "it's definitely
possible to successfully commit as much as you want, in violation of
2-safety, syncrep setting or no," and that seems like an interesting
violation of an invariant one might presume.
The warning is there, but it does render the feature a more fragile
for exposing through the very thin channel one has when dealing with
database users at arm's length, as I must. Only so many caveats and
fine print can be shoved to the user -- this is why, for example,
support of pooling has been a heady proposition for me.
I think this is still in the realm of brain-food, since there is no
obvious model to fix this in sight.
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2012-11-05 22:47:58|
|Subject: Re: What are the advantages of not being able to access
multiple databases with one connection?|
|Previous:||From: Dimitri Fontaine||Date: 2012-11-05 22:22:17|
|Subject: Re: foreign key locks|