Re: Refactoring log_newpage
От | Jim Nasby |
---|---|
Тема | Re: Refactoring log_newpage |
Дата | |
Msg-id | 4FF85E04-6418-4A84-8541-9A868ABA8D75@nasby.net обсуждение исходный текст |
Ответ на | Refactoring log_newpage (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Refactoring log_newpage
|
Список | pgsql-hackers |
On Feb 1, 2012, at 4:25 AM, Simon Riggs wrote: > At present log_newpage() produces log records called XLOG_HEAP_NEWPAGE. > > That routine is used by HEAP, BTREE, GIN, SPGIST rmgrs, as well as > various forks. > > WAL contains no information as to which rmgr the data refers to, > making debugging much harder and skewing efforts to optimise WAL > traffic and is a pretty gross modularity violation of the whole rmgr > concept. > > This refactoring adds an RmgrId field onto each new page record and > makes clearer that certain "heap" routines are actually generic. The > WAL records are still marked as HEAP rmgr and have XLOG_NEWPAGE record > type, but at least we can tell them apart. (We already had forknum, > just not rmgrid). But we already had RelFileNode; wouldn't that be enough to tell what rmgr was responsible for the new page? Can 2 differentrmgrs write to the same file node? -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: