On 10/31/12 9:39 PM, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not cancelled.
Is this expected behaviour?
d5r5fdj6u5ieml= begin;
BEGIN
d5r5fdj6u5ieml= set synchronous_commit = 'on';
SET
d5r5fdj6u5ieml= insert into data values ('baz');
INSERT 0
On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 2 November 2012 16:27, Jeff Janes jeff.ja...@gmail.com wrote:
It would be. But you are not cancelling the commit, you are
*attempting* to cancel the commit. The message you receive explains
to what extend your
On Fri, Nov 2, 2012 at 11:41 AM, Daniel Farina dan...@heroku.com wrote:
On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 2 November 2012 16:27, Jeff Janes jeff.ja...@gmail.com wrote:
It would be. But you are not cancelling the commit, you are
*attempting* to cancel
On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Daniel Farina:
The idea of canceling a COMMIT statement causing a COMMIT seems pretty
strange to me.
Canceling commits is inherently racy, so
On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina dan...@heroku.com wrote:
On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Daniel Farina:
The idea of canceling a COMMIT statement causing a COMMIT
On Mon, Nov 5, 2012 at 1:19 PM, Robert Haas robertmh...@gmail.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
On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Daniel Farina:
The idea of canceling a COMMIT statement causing a COMMIT seems pretty
strange to me.
Canceling commits is inherently racy, so I'm not sure if this behavior
so strange after all.
Yeah. You can't make
On Fri, Nov 2, 2012 at 11:16 AM, Peter Eisentraut pe...@eisentraut.orgwrote:
Did the inserted row also arrive at the standby?
No, as there was no standby.
--
Peter van Hardenberg
San Francisco, California
Everything was beautiful, and nothing hurt. -- Kurt Vonnegut
* Daniel Farina:
The idea of canceling a COMMIT statement causing a COMMIT seems pretty
strange to me.
Canceling commits is inherently racy, so I'm not sure if this behavior
so strange after all.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Fri, Nov 2, 2012 at 1:46 PM, Daniel Farina dan...@heroku.com wrote:
On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I see why it is implemented this way, but it's also still pretty
unsatisfying because it means that with cancellation requests clients
are in theory
On Fri, Nov 2, 2012 at 4:42 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Btw, I believe that this is correct behavior, because in Peter's case the
manual command gets the priority on the value of
On Thu, Nov 1, 2012 at 12:42 PM, Daniel Farina dan...@heroku.com wrote:
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Btw, I believe that this is correct behavior, because in Peter's case the
manual command gets the priority on the value of
On 2 November 2012 16:27, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Nov 1, 2012 at 12:42 PM, Daniel Farina dan...@heroku.com wrote:
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Btw, I believe that this is correct behavior, because in Peter's case the
On 11/02/2012 12:31 PM, Simon Riggs wrote:
If people want full two phase commit, that option exists also.
I was about to say... isn't that what savepoints are for?
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
stho...@optionshouse.com
On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I see why it is implemented this way, but it's also still pretty
unsatisfying because it means that with cancellation requests clients
are in theory able to commit an unlimited number of transactions,
synchronous commit or
On 11/02/2012 09:46 PM, Daniel Farina wrote:
The bar for reliable non-volatile storage for me are things like
Amazon's S3, and I think a lot of that has to do with the otherwise
relatively impoverished semantics it has, so I think this reliability
profile will be or has been duplicated
On Fri, Nov 2, 2012 at 5:08 PM, Hannu Krosing ha...@krosing.net wrote:
On 11/02/2012 09:46 PM, Daniel Farina wrote:
The bar for reliable non-volatile storage for me are things like
Amazon's S3, and I think a lot of that has to do with the otherwise
relatively impoverished semantics it has, so
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter da...@fetter.org wrote:
I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
enough latency for my reflexes to hit ^C fast enough. Any way to
inject this fault deterministically?
If the point is to get this warning, you can
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Btw, I believe that this is correct behavior, because in Peter's case the
manual command gets the priority on the value of synchronous_commit, no?
If anybody thinks that I am wrong, feel free to argue on that of
This was rather surprising - my synchronous commit was... not cancelled. Is
this expected behaviour?
d5r5fdj6u5ieml= begin;
BEGIN
d5r5fdj6u5ieml= set synchronous_commit = 'on';
SET
d5r5fdj6u5ieml= insert into data values ('baz');
INSERT 0 1
d5r5fdj6u5ieml= commit;
^CCancel request sent
WARNING:
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this expected behaviour?
I believe it is.
Does the following do the right thing?
SET synchronous_commit='on';
BEGIN;
INSERT INTO data VALUES
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter da...@fetter.org wrote:
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this expected behaviour?
I believe it is.
Does the following do the
On Thu, Nov 01, 2012 at 01:31:34PM +0900, Michael Paquier wrote:
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter da...@fetter.org wrote:
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this
On Thu, Nov 01, 2012 at 02:10:46PM +0900, Michael Paquier wrote:
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter da...@fetter.org wrote:
I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
enough latency for my reflexes to hit ^C fast enough. Any way to
inject this fault
24 matches
Mail list logo
