Re: Create and drop temp table in 8.3.4

От: Matthew Wakeling
Тема: Re: Create and drop temp table in 8.3.4
Дата: ,
Msg-id: alpine.DEB.1.10.0811111446150.4666@aragorn.flymine.org
(см: обсуждение, исходный текст)
Ответ на: Re: Create and drop temp table in 8.3.4  ("Scott Marlowe")
Список: pgsql-performance

Скрыть дерево обсуждения

Create and drop temp table in 8.3.4  ("Kevin Grittner", )
 Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
 Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
  Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
   Re: Create and drop temp table in 8.3.4  ("Joshua D. Drake", )
    Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
     Re: Create and drop temp table in 8.3.4  ("Scott Carey", )
      Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
      Re: Create and drop temp table in 8.3.4  ("Scott Marlowe", )
       Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
        Re: Create and drop temp table in 8.3.4  ("Scott Marlowe", )
         Re: Create and drop temp table in 8.3.4  ("Kevin Grittner", )
          Re: Create and drop temp table in 8.3.4  ("Scott Marlowe", )
           Re: Create and drop temp table in 8.3.4  ("David Rees", )
           Re: Create and drop temp table in 8.3.4  (Matthew Wakeling, )
    Re: Create and drop temp table in 8.3.4  (Aidan Van Dyk, )
 Re: Create and drop temp table in 8.3.4  (Tom Lane, )

On Thu, 6 Nov 2008, Scott Marlowe wrote:
> Without write barriers, the second we call an fsync it returns true.
>
> But that's assuming write barriers work as I understand them.

Write barriers do not work as you understand them.

Calling fsync always blocks until all the data has made it to safe
storage, and always has (barring broken systems). Write barriers are meant
to be a way to speed up fsync-like operations. Before write barriers, all
the system could do was call fsync, and that would cause the operating
system to wait for a response from the disc subsystem that the data had
been written before it could start writing some more stuff. Write
barriers provide an extra way of telling the disc "Write everything before
the barrier before you write anything after the barrier", which allows the
operating system to keep stuffing data into the disc queue without having
to wait for a response.

So fsync should always work right, unless the system is horribly broken,
on all systems going back many years.

Matthew

--
I'd try being be a pessimist, but it probably wouldn't work anyway.


В списке pgsql-performance по дате сообщения:

От: Andreas Kretschmer
Дата:
Сообщение: Re: Using index for IS NULL query
От: Tomas Vondra
Дата:
Сообщение: Re: Using index for IS NULL query