Re: race condition in sync rep
От | Robert Haas |
---|---|
Тема | Re: race condition in sync rep |
Дата | |
Msg-id | AANLkTikpKk5CpnGd==GOeALLGJcscrFK-opuymSDkAq2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: race condition in sync rep (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: race condition in sync rep
|
Список | pgsql-hackers |
On Sat, Mar 26, 2011 at 12:41 PM, Simon Riggs <simon@2ndquadrant.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@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@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: