Re: Refactoring the checkpointer's fsync request queue
От | Thomas Munro |
---|---|
Тема | Re: Refactoring the checkpointer's fsync request queue |
Дата | |
Msg-id | CA+hUKG+i5+0Grt9O9gtv1YHASP6R3rfb8074or0j=fFoY6YvTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Refactoring the checkpointer's fsync request queue (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Refactoring the checkpointer's fsync request queue
|
Список | pgsql-hackers |
On Sat, Feb 23, 2019 at 11:48 AM Andres Freund <andres@anarazel.de> wrote: > > Yeah I suggested dynamic registration to avoid the problem that eg > > src/backend/storage/sync.c otherwise needs to forward declare > > md_tagtopath(), undofile_tagtopath(), slru_tagtopath(), ..., or maybe > > #include <storage/md.h> etc, which seemed like exactly the sort of > > thing up with which you would not put. > > I'm not sure I understand. If we have a few known tag types, what's the > problem with including the headers with knowledge of how to implement > them into sync.c file? Typo in my previous email: src/backend/storage/file/sync.c was my proposal for the translation unit holding this stuff (we don't have .c files directly under storage). But it didn't seem right that stuff under storage/file (things concerned with files) should know about stuff under storage/smgr (md.c functions, higher level smgr stuff). Perhaps that just means it should go into a different subdir, maybe src/backend/storage/sync/sync.c, that knows about files AND smgr stuff, or perhaps I'm worrying about nothing. -- Thomas Munro https://enterprisedb.com
В списке pgsql-hackers по дате отправления: