Skip site navigation (1) Skip section navigation (2)

Re: Synchronous commit not... synchronous?

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Florian Weimer <fw(at)deneb(dot)enyo(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous commit not... synchronous?
Date: 2012-11-05 22:24:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 BerkusDate: 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 FontaineDate: 2012-11-05 22:22:17
Subject: Re: foreign key locks

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group