From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring log_newpage |
Date: | 2012-02-02 06:19:23 |
Message-ID: | CA+U5nM+k+i40zny-nX5LfNGk-pJcmZv5QQF613A=PRTVqANGGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 1, 2012 at 10:42 PM, Jim Nasby <jim(at)nasby(dot)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. So btree changes look like heap
changes etc..
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-02-02 07:26:09 | Re: Refactoring log_newpage |
Previous Message | Alvaro Herrera | 2012-02-02 04:45:15 | keywords in initdb are case-sensitive? |