Re: race condition in sync rep

On Sat, Mar 26, 2011 at 5:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Mar 26, 2011 at 12:41 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> 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(at)office ~]$ pgbench -T 10
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 25
> query mode: simple
> number of clients: 1
> number of threads: 1
> duration: 10 s
> number of transactions actually processed: 27
> tps = 0.099386 (including connections establishing)
> tps = 0.099389 (excluding connections establishing)
> [rhaas(at)office ~]$ pgbench -T 10
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 25
> query mode: simple
> number of clients: 1
> number of threads: 1
> duration: 10 s
> number of transactions actually processed: 425
> tps = 42.442185 (including connections establishing)
> tps = 42.468972 (excluding connections establishing)
>
> The first one - run with code from a few weeks ago - hung up on the
> 27th transaction and was stuck there until the next checkpoint
> completed.  The second one was run with the latest code and no longer
> hangs - and in fact it's now faster than running with fsync=on,
> exactly as one would expect.  Or at least as *I* expected.

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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services