Thread: 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