Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

Поиск
Список
Период
Сортировка
От Alfred Perlstein
Тема Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Дата
Msg-id 20001116133630.N830@fw.wintelcom.net
обсуждение исходный текст
Ответ на Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [001116 13:31] wrote:
> Alfred Perlstein <bright@wintelcom.net> writes:
> > It might make more sense to keep a private copy of the last time
> > the file was modified per-backend by that particular backend and
> > a timestamp of the last fsync shared globally so one can forgo the
> > fsync if "it hasn't been dirtied by me since the last fsync"
> > This would provide a rendevous point for the fsync call although
> > cost more as one would need to periodically call gettimeofday to
> > set the modified by me timestamp as well as the post-fsync shared
> > timestamp.
> 
> That's the hard way to do it.  We just need to keep track of the
> endpoint of the log as of the last fsync.  You need to fsync (after
> returning from sleep()) iff your commit record position > fsync
> endpoint.  No need to ask the kernel for time-of-day.

Well that breaks when you move to a overwriting storage manager,
however if you use oid instead that optimization would survive
the change to a overwriting storage manager.  ?

-Alfred


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Следующее
От: Alfred Perlstein
Дата:
Сообщение: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)