Thread: Synchronous commit not... synchronous?
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: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
COMMIT
d5r5fdj6u5ieml=> select * from data;
foo
-----
bar
baz
(2 rows)
d5r5fdj6u5ieml=> rollback;
NOTICE: there is no transaction in progress
ROLLBACK
d5r5fdj6u5ieml=>
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
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 ('baz');
COMMIT;^c
Oh, and how did you get that cancel in?
Cheers,
David.
>
> d5r5fdj6u5ieml=> begin;
> BEGIN
> d5r5fdj6u5ieml=> set synchronous_commit = 'on';
> SET
> d5r5fdj6u5ieml=> insert into data values ('baz');
> INSERT 0 1
> d5r5fdj6u5ieml=> commit;
> ^CCancel request sent
> WARNING: canceling wait for synchronous replication due to user request
> DETAIL: The transaction has already committed locally, but might not have
> been replicated to the standby.
> COMMIT
> d5r5fdj6u5ieml=> select * from data;
> foo
> -----
> bar
> baz
> (2 rows)
>
> d5r5fdj6u5ieml=> rollback;
> NOTICE: there is no transaction in progress
> ROLLBACK
> d5r5fdj6u5ieml=>
>
>
> --
> Peter van Hardenberg
> San Francisco, California
> "Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter <david@fetter.org> wrote:
-- On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:I believe it is.
> This was rather surprising - my synchronous commit was... not
> cancelled. Is this expected behaviour?
Does the following do the right thing?
SET synchronous_commit='on';
BEGIN;
INSERT INTO data VALUES ('baz');
COMMIT;^c
Oh, and how did you get that cancel in?
He enforced a manual cancel from client with something like Ctrl+C to cancel query.
In this case you do not wait for the slave to confirm that the commit information has been flushed on its disk.
In this case you do not wait for the slave to confirm that the commit information has been flushed on its disk.
Michael Paquier
http://michael.otacoo.com
On Thu, Nov 01, 2012 at 01:31:34PM +0900, Michael Paquier wrote:
> On Thu, Nov 1, 2012 at 1:03 PM, David Fetter <david@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 right thing?
> >
> > SET synchronous_commit='on';
> > BEGIN;
> > INSERT INTO data VALUES ('baz');
> > COMMIT;^c
> >
> > Oh, and how did you get that cancel in?
> >
> He enforced a manual cancel from client with something like Ctrl+C to
> cancel query.
> In this case you do not wait for the slave to confirm that the commit
> information has been flushed on its disk.
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?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Nov 01, 2012 at 02:10:46PM +0900, Michael Paquier wrote: > On Thu, Nov 1, 2012 at 1:48 PM, David Fetter <david@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 always setup > synchronous_standby_names with the application name of a slave that is not > listed in pg_stat_replication to make the master hanging for a slave that > does not exist :) > But in this case there is virtually no slave to wait for, so perhaps it has > no meaning... But it lets you all time you want to do a manual cancel and > get this warning. Great idea :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter <david@fetter.org> wrote:
--
Michael Paquier
http://michael.otacoo.com
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 always setup synchronous_standby_names with the application name of a slave that is not listed in pg_stat_replication to make the master hanging for a slave that does not exist :)
But in this case there is virtually no slave to wait for, so perhaps it has no meaning... But it lets you all time you want to do a manual cancel and get this warning.
For example:
postgres=# show synchronous_standby_names;
synchronous_standby_names
---------------------------
slave2
(1 row)
postgres=# select application_name, sync_state from pg_stat_replication;
application_name | sync_state
------------------+------------
slave1 | async
(1 row)
postgres=# begin;
BEGIN
postgres=# create table aa (a int);
CREATE TABLE
postgres=# commit;
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
COMMIT
postgres=# show synchronous_commit;
synchronous_commit
--------------------
on
(1 row)
postgres=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | aa | table | michael
(1 row)
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 course...
But in this case there is virtually no slave to wait for, so perhaps it has no meaning... But it lets you all time you want to do a manual cancel and get this warning.
For example:
postgres=# show synchronous_standby_names;
synchronous_standby_names
---------------------------
slave2
(1 row)
postgres=# select application_name, sync_state from pg_stat_replication;
application_name | sync_state
------------------+------------
slave1 | async
(1 row)
postgres=# begin;
BEGIN
postgres=# create table aa (a int);
CREATE TABLE
postgres=# commit;
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
COMMIT
postgres=# show synchronous_commit;
synchronous_commit
--------------------
on
(1 row)
postgres=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+---------
public | aa | table | michael
(1 row)
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 course...
Michael Paquier
http://michael.otacoo.com
On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier <michael.paquier@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 course... The idea of canceling a COMMIT statement causing a COMMIT seems pretty strange to me. I would also not expect a cancelled INSERT statement to INSERT, as seems would happen by applying the same rules in the autocommit/implicit commit case here. -- fdr
On Fri, Nov 2, 2012 at 4:42 AM, Daniel Farina <daniel@heroku.com> wrote: > On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier > <michael.paquier@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 course... > > The idea of canceling a COMMIT statement causing a COMMIT seems pretty > strange to me. > > I would also not expect a cancelled INSERT statement to INSERT, as > seems would happen by applying the same rules in the > autocommit/implicit commit case here. So how should we handle the case where cancel request or SIGINT arrives while COMMIT is waiting for its WAL to be replicated to the standby? It's hard to rollback the COMMIT because its WAL has already been flushed to the disk locally. You think that we should prevent COMMIT at that state from being canceled? Regards, -- Fujii Masao
On Thu, Nov 1, 2012 at 12:42 PM, Daniel Farina <daniel@heroku.com> wrote: > On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier > <michael.paquier@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 course... > > The idea of canceling a COMMIT statement causing a COMMIT seems pretty > strange to me. 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 attempt succeeded. Cheers, Jeff
On 2 November 2012 16:27, Jeff Janes <jeff.janes@gmail.com> wrote: > On Thu, Nov 1, 2012 at 12:42 PM, Daniel Farina <daniel@heroku.com> wrote: >> On Wed, Oct 31, 2012 at 10:10 PM, Michael Paquier >> <michael.paquier@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 course... >> >> The idea of canceling a COMMIT statement causing a COMMIT seems pretty >> strange to me. > > 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 attempt succeeded. That is correct. It is possible to cancel the COMMIT, but only until it happens. If people want full two phase commit, that option exists also. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
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 sthomas@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes <jeff.janes@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 no. > > What evil does this allow the client to perpetrate? The client can commit against my will by accident in an automated system whose behavior is at least moderately complex and hard to understand completely for all involved, and then the client's author subsequently writes me a desperate or angry support request asking why data was lost. This is not the best time for me to ask "did you setup a scheduled task to cancel hanging queries automatically? Because yeah...there's this...thing." >> It's probably close enough for most purposes, but what would you think >> about a "2PC-ish" mode at the physical (rather than logical/PREPARE >> TRANSACTION) level, whereby the master would insist that its standbys >> have more data written (or at least received...or at least sent) than >> it has guaranteed flushed to its own xlog at any point? > > Then if they interrupt the commit, the remote has it permanently but > the local does not. That would be corruption. That is a good point. When the server starts up it could interrogate it standbys for WAL to apply. My ideal is to get a similar relationship between a master and its 'local' pg_xlog, except over socket, and possibly (but entirely optionally) to a non-Postgres receiver of WAL, that may buffer WAL and then submit it directly to what is typically thought of as the archives. I have a number of reasons for doing that, but they can all be summed as: block devices are much more prone to failures -- both simple and byzantine -- than memory and network traffic with enough fidelity checking (such as TLS), and the pain from block device failures -- in particular, the byzantine ones -- is very high when they occur. 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 elsewhere. In general, this has some relation to remastering issues. In the future, I'd like to be able to turn off the local pg_xlog, at my option. This is something that I've been very slowly moving forward on for a while, with the first step being writing a Postgres proxy, currently underway. The tool support for this kind of facility is not really in existence yet, but I'll catch up some day... > What the "DETAIL" doesn't make clear about the current system is that > the commit *will* be replicated to the standby *eventually*, unless > the master burns down first. In particular, if any commit after this > one makes it to the standby, then the interrupted one is guaranteed to > have made it as well. > >> This would be a nice invariant to have when dealing with a large >> number of systems, allowing for the catching of some tricky bugs, that >> standbys are always greater-than-or-equal-to the master's XLogPos. > > Could you elaborate on that? Sure. I'd like to sanity check failovers with as many simple invariants as I can to catch problems. Losing a cheap to confirm invariant is losing a check, so that would be unfortunate when doing more failovers simultaneously than humans can realistically be involved with in a short amount of time, as the results of a bug there are most unpleasant. -- fdr
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 elsewhere. > > In general, this has some relation to remastering issues. > > In the future, I'd like to be able to turn off the local pg_xlog, at my option. Have you tried things like mounting remote RAM drive over NFS or similar for pg_xlog ? You probably could even play with DRBD and have one or both of the drives be RAM drives. Hannu
On Fri, Nov 2, 2012 at 5:08 PM, Hannu Krosing <hannu@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 I think this reliability >> profile will be or has been duplicated elsewhere. >> >> In general, this has some relation to remastering issues. >> >> In the future, I'd like to be able to turn off the local pg_xlog, at my >> option. > > Have you tried things like mounting remote RAM drive > over NFS or similar for pg_xlog ? > > You probably could even play with DRBD and have one or both > of the drives be RAM drives. > > Hannu I'm not so interested in such creative workarounds, especially because the operational maintenance cost is huge when magnified when all I wish I could do is buffer WAL and forward to a socket, and then unblock commits when my replication partner says 'alright', just as they do in spirit for flushing pg_xlog -- what I want is simpler than a full blown network file system. I also don't need this kind of thing in the near future -- I'm way behind what's possible as-is. And then there are issues like transport encryption and being able to do this across a geography, ugh. -- fdr
* 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.
On Fri, Nov 2, 2012 at 1:46 PM, Daniel Farina <daniel@heroku.com> wrote: > On Fri, Nov 2, 2012 at 1:06 PM, Jeff Janes <jeff.janes@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 no. >> >> What evil does this allow the client to perpetrate? > > The client can commit against my will by accident in an automated > system whose behavior is at least moderately complex and hard to > understand completely for all involved, and then the client's author > subsequently writes me a desperate or angry support request asking why > data was lost. If people don't know when or if they are committing, then I would think you will get such issues no matter what! > This is not the best time for me to ask "did you setup > a scheduled task to cancel hanging queries automatically? Because > yeah...there's this...thing." OK, I see your point here. If an outside task cancels the commit, the process that issued the commit does get a success response with seemingly no indication that something may be amiss. In DBD::Pg under PrintError=>1, you do get the WARNING and DETAIL message on stderr, but seemingly no sane way for the program to intercept that warning. But I don't see any alternative, other than refusing to deliver any response at all to the client. The commit neither unambiguously failed, nor unambiguously succeeded. Cheers, Jeff
On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <fw@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 the local fsync() and the remote fsync() happen at exactly the same moment in time. No implementation can do that, anywhere, ever. Our implementation happens to require the local fsync() to always be done first. With sufficient smarts, that could possibly be relaxed to allow them to run concurrently (if after a crash the master tried to fetch remotely committed WAL from its slave), but you still have the possibility that one fsync gets done and the other does not, and that would actually allow more weird edge cases than we have now - the main argument for it is performance. And because of the way our WAL stream works, once the commit record is fsync'd, it's too late to get cold feet. I daresay that will be true in any system, too. Once the local commit record hits the disk, the absolute best you could do, even theoretically, is *try* to take it back. And you had better be prepared for that to fail, because the system might crash or the take-back write might itself fail. Atomicity in a distributed system is not an easy problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Nov 2, 2012 at 11:16 AM, Peter Eisentraut <peter@eisentraut.org> wrote:
No, as there was no standby.
--
Peter van Hardenberg
San Francisco, California
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
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
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 1
> d5r5fdj6u5ieml=> commit;
> ^CCancel request sent
> WARNING: canceling wait for synchronous replication due to user request
> DETAIL: The transaction has already committed locally, but might not
> have been replicated to the standby.
> COMMIT
> d5r5fdj6u5ieml=> select * from data;
> foo
> -----
> bar
> baz
> (2 rows)
Did the inserted row also arrive at the standby?
On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 2 November 2012 16:27, Jeff Janes <jeff.janes@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 attempt succeeded. > > That is correct. > > It is possible to cancel the COMMIT, but only until it happens. > > If people want full two phase commit, that option exists also. 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 no. It's probably close enough for most purposes, but what would you think about a "2PC-ish" mode at the physical (rather than logical/PREPARE TRANSACTION) level, whereby the master would insist that its standbys have more data written (or at least received...or at least sent) than it has guaranteed flushed to its own xlog at any point? This would be a nice invariant to have when dealing with a large number of systems, allowing for the catching of some tricky bugs, that standbys are always greater-than-or-equal-to the master's XLogPos. -- fdr
On Fri, Nov 2, 2012 at 11:41 AM, Daniel Farina <daniel@heroku.com> wrote: > On Fri, Nov 2, 2012 at 10:31 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On 2 November 2012 16:27, Jeff Janes <jeff.janes@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 attempt succeeded. >> >> That is correct. >> >> It is possible to cancel the COMMIT, but only until it happens. >> >> If people want full two phase commit, that option exists also. > > 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 no. What evil does this allow the client to perpetrate? > It's probably close enough for most purposes, but what would you think > about a "2PC-ish" mode at the physical (rather than logical/PREPARE > TRANSACTION) level, whereby the master would insist that its standbys > have more data written (or at least received...or at least sent) than > it has guaranteed flushed to its own xlog at any point? Then if they interrupt the commit, the remote has it permanently but the local does not. That would be corruption. What the "DETAIL" doesn't make clear about the current system is that the commit *will* be replicated to the standby *eventually*, unless the master burns down first. In particular, if any commit after this one makes it to the standby, then the interrupted one is guaranteed to have made it as well. > This would be a nice invariant to have when dealing with a large > number of systems, allowing for the catching of some tricky bugs, that > standbys are always greater-than-or-equal-to the master's XLogPos. Could you elaborate on that? Cheers, Jeff
On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <fw@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 the local fsync() and the remote fsync() happen > at exactly the same moment in time. No implementation can do that, > anywhere, ever. Our implementation happens to require the local > fsync() to always be done first. I don't think there is a (unachievable) requirement of simultaneous flush, only that two machines have flushed (or met whatever durability criteria) strictly more than the position of the commit in question. This mean some changes are written to some place once, but acknowledging commit requires proof of two-safety. I can see how in some corner cases this might cause orphaning of synchronous standbys that write, but cannot acknowledge. If the point of synchronous commit is to reach exact two-safety by waiting a while for other agents to process data, it would seem that the current model could use some less-invasive tweaking, as-is one can succeed in an unbounded number of commits in a degenerate case. -- fdr
On Mon, Nov 5, 2012 at 2:59 PM, Daniel Farina <daniel@heroku.com> wrote: > On Sun, Nov 4, 2012 at 6:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Sat, Nov 3, 2012 at 5:44 PM, Florian Weimer <fw@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 the local fsync() and the remote fsync() happen >> at exactly the same moment in time. No implementation can do that, >> anywhere, ever. Our implementation happens to require the local >> fsync() to always be done first. > > I don't think there is a (unachievable) requirement of simultaneous > flush, only that two machines have flushed (or met whatever durability > criteria) strictly more than the position of the commit in question. > This mean some changes are written to some place once, but > acknowledging commit requires proof of two-safety. Right, but what you're complaining about is that you can't cancel the transaction after beginning to make it 2-safe. > I can see how in some corner cases this might cause orphaning of > synchronous standbys that write, but cannot acknowledge. > > If the point of synchronous commit is to reach exact two-safety by > waiting a while for other agents to process data, it would seem that > the current model could use some less-invasive tweaking, as-is one can > succeed in an unbounded number of commits in a degenerate case. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Nov 5, 2012 at 1:19 PM, Robert Haas <robertmhaas@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 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. -- fdr