Refactoring log_newpage - Mailing list pgsql-hackers

From Simon Riggs
Subject Refactoring log_newpage
Date
Msg-id CA+U5nM+zRO2WAMq_gLbhGompMJNs-p5bJrJh8LgaMD-VDv2Utg@mail.gmail.com
Whole thread Raw
Responses Re: Refactoring log_newpage
List 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

pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Speed dblink using alternate libpq tuple storage
Next
From: Chetan Suttraway
Date:
Subject: patch for implementing SPI_gettypemod()