Re: Cache relation sizes?

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Cache relation sizes?
Дата
Msg-id CA+hUKGKMMpHxSWZg2sW0=EmZnbN00yejkjYNxZr=z+Xn=eEzSg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cache relation sizes?  (Andy Fan <zhihui.fan1213@gmail.com>)
Ответы Re: Cache relation sizes?  (Andy Fan <zhihui.fan1213@gmail.com>)
Список pgsql-hackers
Hi Andy,

On Thu, Dec 17, 2020 at 7:29 PM Andy Fan <zhihui.fan1213@gmail.com> wrote:
> I spent one day studying the patch and I want to talk about one question for now.
> What is the purpose of calling smgrimmedsync to evict a DIRTY sr (what will happen
> if we remove it and the SR_SYNCING and SR_JUST_DIRTIED flags)?

The underlying theory of the patch is that after fsync() succeeds, the
new size is permanent, but before that it could change at any time
because of asynchronous activities in the kernel*.  Therefore, if you
want to evict the size from shared memory, you have to fsync() the
file first.  I used smgrimmedsync() to do that.

*I suspect that it can really only shrink with network file systems
such as NFS and GlusterFS, where the kernel has to take liberties to
avoid network round trips for every file extension, but I don't know
the details on all 9 of our supported OSes and standards aren't very
helpful for understanding buffered I/O.



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

Предыдущее
От: Önder Kalacı
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module