pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Jim Nasby <jim@nasby.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Refactoring log_newpage
Date: Thu, 02 Feb 2012 09:26:09 +0200
Message-ID: <4F2A3A91.4070001@enterprisedb.com> (raw)
In-Reply-To: <CA+U5nM+k+i40zny-nX5LfNGk-pJcmZv5QQF613A=PRTVqANGGw@mail.gmail.com>
References: <CA+U5nM+zRO2WAMq_gLbhGompMJNs-p5bJrJh8LgaMD-VDv2Utg@mail.gmail.com>
	<4FF85E04-6418-4A84-8541-9A868ABA8D75@nasby.net>
	<CA+U5nM+k+i40zny-nX5LfNGk-pJcmZv5QQF613A=PRTVqANGGw@mail.gmail.com>

On 02.02.2012 08:19, Simon Riggs wrote:
> On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby<jim@nasby.net>  wrote:
>> 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 different rmgrs write to the same file node?
>
> No, but which one? No way to tell unless you have full list of
> relfilenodes and check each one.

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

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com



view thread (7+ messages)  latest in thread

Message-ID: <4F2A3A91.4070001@enterprisedb.com>
Permalink:  ../4F2A3A91.4070001@enterprisedb.com/
Also on:    postgresql.org/message-id/4F2A3A91.4070001@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: heikki.linnakangas@enterprisedb.com, simon@2ndQuadrant.com, jim@nasby.net
  Subject: Re: Refactoring log_newpage
  In-Reply-To: <4F2A3A91.4070001@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox