Re: Simplifying wal_sync_method

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Simplifying wal_sync_method
Дата
Msg-id 42F7EEA2.1020002@dunslane.net
обсуждение исходный текст
Ответ на Re: Simplifying wal_sync_method  (Simon Riggs <simon@2ndquadrant.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Simplifying wal_sync_method
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Solving the OID-collision problem