Re: New statistics for WAL buffer dirty writes

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: New statistics for WAL buffer dirty writes
Дата
Msg-id CAMkU=1xFFaonqsVm66QFE-jvirrKw4ug8Xbb-NdUXUaM-C5N7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New statistics for WAL buffer dirty writes  (Satoshi Nagayasu <snaga@uptime.jp>)
Ответы Re: New statistics for WAL buffer dirty writes  (Robert Haas <robertmhaas@gmail.com>)
Re: New statistics for WAL buffer dirty writes  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu <snaga@uptime.jp> wrote:
> Hi,
>
> Jeff Janes has pointed out that my previous patch could hold
> a number of the dirty writes only in single local backend, and
> it could not hold all over the cluster, because the counter
> was allocated in the local process memory.
>
> That's true, and I have fixed it with moving the counter into
> the shared memory, as a member of XLogCtlWrite, to keep total
> dirty writes in the cluster.

A concern I have is whether the XLogCtlWrite *Write pointer needs to
be declared volatile, to prevent the compiler from pushing operations
on them outside of the locks (and so memory barriers) that formally
protect them.  However I see that existing code with Insert also does
not use volatile, so maybe my concern is baseless.  Perhaps the
compiler guarantees to not move operations on pointers over the
boundaries of function calls?  The pattern elsewhere in the code seems
to be to use volatiles for things protected by spin-locks (implemented
by macros) but not for things protected by LWLocks.

The comment "XLogCtrlWrite must be protected with WALWriteLock"
mis-spells XLogCtlWrite.

The final patch will need to add a sections to the documentation.

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SP-GiST for ranges based on 2d-mapping and quad-tree
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SP-GiST for ranges based on 2d-mapping and quad-tree