On 02.02.2012 11:35, Simon Riggs wrote:
On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas
wrote:
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?
On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas
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?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
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 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.
