Refactoring log_newpage

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Refactoring log_newpage
Date: 2012-02-01 10:25:58
Message-ID: CA+U5nM+zRO2WAMq_gLbhGompMJNs-p5bJrJh8LgaMD-VDv2Utg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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).

Another refactoring option would be to have specific record types for
each rmgr, and would normally be my preferred option but that seems
likely to use up too many record type numbers in the index rmgrs.

For immediate commit.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
refactor_newpage.v1.patch text/x-diff 10.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2012-02-01 11:15:57 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Chetan Suttraway 2012-02-01 10:23:53 patch for implementing SPI_gettypemod()