Re: Simplifying wal_sync_method - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Simplifying wal_sync_method
Date
Msg-id 42F7EEA2.1020002@dunslane.net
Whole thread Raw
In response to Re: Simplifying wal_sync_method  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Simplifying wal_sync_method  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Simplifying wal_sync_method  (Kris Jurka <books@ejurka.com>)
Re: Simplifying wal_sync_method  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers

Simon Riggs wrote:

>On Mon, 2005-08-08 at 17:44 -0400, Bruce Momjian wrote:
>  
>
>>In summary, we added all those wal_sync_method values in hopes of
>>getting some data on which is best on which platform, but having gone
>>several years with few reports, I am thinking we should just choose the
>>best ones we can and move on, rather than expose a confusing API to the
>>users.
>>    
>>
>
>I agree this should be attempted over the 8.1 beta period.
>
>This is a good case for having a Port Coordinator assigned for each
>port, so we could ask them to hunt out the solution for their platform.
>Maybe this is something that we can broadcast to the BuildFarm team, so
>each person can reflect on the appropriate settings?
>
>
>  
>

It might be possible to build a new set of tests that we could perform. 
That would have to be built into the buildfarm script, as the PL tests 
were, but they were picked up pretty quickly by the community. 
Unfortunately it doesn't sound like these would fit into the pg_regress 
setup, so we'll have to devise a different test harness - probably not a 
bad idea for automated performance testing anyway.

So the short answer is possibly "You build the tests and we'll run 'em."

cheers

andrew


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Simplifying wal_sync_method
Next
From: Tom Lane
Date:
Subject: Re: Solving the OID-collision problem