Re: Refactoring log_newpage
От | Heikki Linnakangas |
---|---|
Тема | Re: Refactoring log_newpage |
Дата | |
Msg-id | 4F2A5BBF.7020900@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Refactoring log_newpage (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On 02.02.2012 11:35, Simon Riggs wrote: > On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: > >> Well, you can obviously check the catalogs for that, but you must be >> assuming that you don't have access to the catalogs or this would be a >> non-issue. >> >> You can also identify the kind of page by looking at the special area of the >> stored page. See: >> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00392.php > > How does that work with different forks? You have the fork number explicitly in the newpage record already. > I think its very ugly to mark all sorts of different pages as if they > were heap pages when they clearly aren't. I don't recall anything so > ugly being allowed anywhere else in the system. Why is it *needed* > here? It's not needed. Beauty is in the eye of the beholder, but I don't find it all that ugly, and the comment in log_newpage explains it well. I don't see much value in adding a new field to the record. Any tools that read the WAL format will need to be taught about that change. Not a huge issue, but I also don't see much gain. On the whole I'd be inclined to just leave it all alone, but whatever. I don't think it's a good idea to rename XLOG_HEAP_NEWPAGE to XLOG_NEWPAGE. The WAL record is still part of the heapam rmgr, even if it's used by other access methods, too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: