Re: [HACKERS] race condition in sync rep

2011-03-27 Thread Robert Haas
On Sun, Mar 27, 2011 at 7:46 AM, Simon Riggs wrote: > Are the master and standby on same system or are they separated by a network? > > I'm surprised that a network roundtrip takes less time than the > backend takes to mark clog and then queue for the SyncRepLock. When I first noticed that it was

Re: [HACKERS] race condition in sync rep

2011-03-27 Thread Simon Riggs
On Sun, Mar 27, 2011 at 6:07 PM, Kevin Grittner wrote: > Simon Riggs  wrote: > >> I'm surprised that a network roundtrip takes less time than the >> backend takes to mark clog and then queue for the SyncRepLock. > > I'm not surprised by that at all.  Some of our replication involves > Gb or faster

Re: [HACKERS] race condition in sync rep

2011-03-27 Thread Kevin Grittner
Simon Riggs wrote: > I'm surprised that a network roundtrip takes less time than the > backend takes to mark clog and then queue for the SyncRepLock. I'm not surprised by that at all. Some of our replication involves Gb or faster connections on the same LAN segment (sometimes on the same swit

Re: [HACKERS] race condition in sync rep

2011-03-27 Thread Simon Riggs
On Sat, Mar 26, 2011 at 5:51 PM, Robert Haas wrote: > On Sat, Mar 26, 2011 at 12:41 PM, Simon Riggs wrote: >> Is it? Sync rep requires fsync on the standby. If you then explicitly >> turn off fsync on the standby then it has a performance impact, as >> documented. > > Actually, it doesn't, now th

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Tom Lane
Simon Riggs writes: > On Sat, Mar 26, 2011 at 4:24 PM, Tom Lane wrote: >> Well, in that case, it should be on the open-items list.  If the system >> is still behaving that way, it's a bug. > Is it? Sync rep requires fsync on the standby. If you then explicitly > turn off fsync on the standby the

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Robert Haas
On Sat, Mar 26, 2011 at 12:41 PM, Simon Riggs wrote: > Is it? Sync rep requires fsync on the standby. If you then explicitly > turn off fsync on the standby then it has a performance impact, as > documented. Actually, it doesn't, now that you fixed this. Before: [rhaas@office ~]$ pgbench -T 10

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Simon Riggs
On Sat, Mar 26, 2011 at 4:24 PM, Tom Lane wrote: > Simon Riggs writes: >> On Sat, Mar 26, 2011 at 4:04 PM, Tom Lane wrote: >>> In particular, in view of today's fix, shouldn't this commit be reverted? >>> >>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6e8e7cc580665ddd43c8ca

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Robert Haas
On Mar 26, 2011, at 12:24 PM, Tom Lane wrote: > Simon Riggs writes: >> On Sat, Mar 26, 2011 at 4:04 PM, Tom Lane wrote: >>> In particular, in view of today's fix, shouldn't this commit be reverted? >>> >>> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6e8e7cc580665ddd43c8ca2a

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Simon Riggs
On Sat, Mar 26, 2011 at 3:00 PM, Robert Haas wrote: > On Mar 26, 2011, at 6:16 AM, Simon Riggs wrote: >> That seems very unlikely even with fsync=off in a real config where we >> have network path to consider. >> >> Your definition of a "nasty" race condition seems off. >> >> I've added code for

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Tom Lane
Simon Riggs writes: > On Sat, Mar 26, 2011 at 4:04 PM, Tom Lane wrote: >> In particular, in view of today's fix, shouldn't this commit be reverted? >> >> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6e8e7cc580665ddd43c8ca2acc6d60f345570a57 >> >> I thought at the time that th

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Simon Riggs
On Sat, Mar 26, 2011 at 4:04 PM, Tom Lane wrote: > Robert Haas writes: >>> I've added code for you. > >> Your skepticism seems out of place. I actually hit this problem in testing. >> We could debate how realistic my test setup was, but why?  It is not our >> policy - and bad practice in genera

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Tom Lane
Robert Haas writes: >> I've added code for you. > Your skepticism seems out of place. I actually hit this problem in testing. > We could debate how realistic my test setup was, but why? It is not our > policy - and bad practice in general - to ship code with race conditions. > The code you a

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Robert Haas
On Mar 26, 2011, at 6:16 AM, Simon Riggs wrote: > That seems very unlikely even with fsync=off in a real config where we > have network path to consider. > > Your definition of a "nasty" race condition seems off. > > I've added code for you. Your skepticism seems out of place. I actually hit th

Re: [HACKERS] race condition in sync rep

2011-03-26 Thread Simon Riggs
On Sat, Mar 26, 2011 at 1:11 AM, Robert Haas wrote: > I believe I've figured out why synchronous replication has such > terrible performance with fsync=off: it has a nasty race condition. > It may happen - if the standby responds very quickly - that the > standby acks the commit record and awaken

[HACKERS] race condition in sync rep

2011-03-25 Thread Robert Haas
I believe I've figured out why synchronous replication has such terrible performance with fsync=off: it has a nasty race condition. It may happen - if the standby responds very quickly - that the standby acks the commit record and awakens waiters before the committing backend actually begins to wai