Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure if people want this for 8.2. I think we can modify
> > test_fsync.c anytime but the movement of the defines into an include
> > file is a backend code change.
>
> I think fooling with this on the day before RC1 is an unreaso
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure if people want this for 8.2. I think we can modify
> > test_fsync.c anytime but the movement of the defines into an include
> > file is a backend code change.
>
> I think fooling with this on the day before RC1 is an unreaso
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not sure if people want this for 8.2. I think we can modify
> test_fsync.c anytime but the movement of the defines into an include
> file is a backend code change.
I think fooling with this on the day before RC1 is an unreasonable risk ...
and I disappr
Greg Smith wrote:
> On Thu, 23 Nov 2006, Tom Lane wrote:
>
> > * It does not check for errors (if it had, you might have realized the
> > other problem).
>
> All the test_fsync code needs to check for errors better; there have been
> multiple occasions where I've run that with quesiontable inpu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have applied your test_fsync patch for 8.2. Thanks.
>
> ... which means test_fsync is now broken. Why did you apply a patch
> when the author pointed out that the program isn't working?
I thought his code was OK, but the OS had i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have applied your test_fsync patch for 8.2. Thanks.
... which means test_fsync is now broken. Why did you apply a patch
when the author pointed out that the program isn't working?
regards, tom lane
--
I have applied your test_fsync patch for 8.2. Thanks.
---
Greg Smith wrote:
> I've been trying to optimize a Linux system where benchmarking suggests
> large performance differences between the various wal_sync_method opti
