Are we done with sync-commit-defaults-to-off patch?
When I was playing with pgbench testing yesterday, one thing that seemed
a bit odd was that turning off synchronous_commit didn't change the
results noticeably. It took till today for the reason to penetrate
my cranium: it was off already.
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00355.php
http://archives.postgresql.org/pgsql-committers/2007-08/msg00182.php
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This is particularly
the case since Andrew has worked up a pg_regress enhancement that would
let specific buildfarm animals still test the "off" setting if they
chose.
Comments?
regards, tom lane
Tom Lane wrote:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This is particularly
the case since Andrew has worked up a pg_regress enhancement that would
let specific buildfarm animals still test the "off" setting if they
chose.
+1
I will commit the pg_regress change. There are several buildfarm client
changes in the queue - I will add a facility to take advantage of this
and get out a new release of the client.
cheers
andrew
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This is particularly
the case since Andrew has worked up a pg_regress enhancement that would
let specific buildfarm animals still test the "off" setting if they
chose.
I thought the idea was more to have people playing the home game to test it
out. They're much more likely to do something unexpected than the build farm.
Especially when it comes to vacuum and vacuum full and cluster and so on given
that autovacuum barely has a chance to start looking at things before the
regression tests are done.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance.
I thought the idea was more to have people playing the home game to test it
out. They're much more likely to do something unexpected than the build farm.
True, but I hope some of that has happened already.
At this point I feel that we can't let the default-off patch persist
into beta, which means there is not a lot more testing we can get from
it. The scenario I'm foreseeing is somebody runs performance tests on
8.3beta (failing to realize that he's testing sync-commit off),
publishes some amazing numbers, and then the release version is a lot
worse. That will be a public-relations disaster.
We can do everything we can to encourage beta-testers to test the
sync-commit-off mode, but I don't want people to not know what they
are testing.
regards, tom lane
Gregory Stark wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
We've had that hack in there for almost a month now, and no strange
behaviors have turned up in the buildfarm. So I'm inclined to think
it has served its purpose, and we should revert it before anyone else
comes to bogus conclusions about performance. This is particularly
the case since Andrew has worked up a pg_regress enhancement that would
let specific buildfarm animals still test the "off" setting if they
chose.I thought the idea was more to have people playing the home game to test it
out. They're much more likely to do something unexpected than the build farm.
Especially when it comes to vacuum and vacuum full and cluster and so on given
that autovacuum barely has a chance to start looking at things before the
regression tests are done.
Maybe we should lower the autovac naptime too, just to make it do some
more stuff (and to see if it breaks something else just because of being
running).
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
You liked Linux a lot when he was just the gawky kid from down the block
mowing your lawn or shoveling the snow. But now that he wants to date
your daughter, you're not so sure he measures up. (Larry Greenemeier)
Alvaro Herrera <alvherre@commandprompt.com> writes:
Maybe we should lower the autovac naptime too, just to make it do some
more stuff (and to see if it breaks something else just because of being
running).
Well, Andrew has committed the pg_regress extension to allow buildfarm
animals to set nondefault GUC values. So I think it'd be sufficient if
a buildfarm owner or two would volunteer to run with small autovac
naptime.
regards, tom lane
Tom Lane wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Maybe we should lower the autovac naptime too, just to make it do some
more stuff (and to see if it breaks something else just because of being
running).Well, Andrew has committed the pg_regress extension to allow buildfarm
animals to set nondefault GUC values. So I think it'd be sufficient if
a buildfarm owner or two would volunteer to run with small autovac
naptime.
What settings do you have in mind for a testing regime?
If anyone wants help on setting this up for a buildfarm member, please
let me know.
cheers
andrew