Re: Refactoring log_newpage
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Jim Nasby <jim@nasby.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-02-02T09:47:43Z
Lists: 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